[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shim6-proto-07 review
Hi Iljitsch,
sorry for the delay and thank you for the review...
I have sent a separate reply to the most substantial issues. for the
remaining issues (which are many and not all of them editorial), i
comment below...
El 11/12/2006, a las 19:54, Iljitsch van Beijnum escribió:
(Note that I'm behind on the shim6 list so I'm not aware of recently
discussed issues, so these may be duplicated here.)
This is a review of the shim proto 07 draft. It contains both nits and
more fundamental issues, they are presented in the order of the text,
but let me get two other things out of the way first:
1. Always including the context tag
sent a separate email for this
2. Congestion
There is no discussion of congestion issues when the shim moves
ongoing communicaiton to another locator pair, which will generally
make the communication flow over a different path. We've had some
discussions about this before, where the suggestion was made to go
into slow start after a rehoming event. The counter argument: but
maybe the new path is just as fast as the old one. My counter counter
argument: suppose a file transfer over a 1 Gbps link, the Gbps link
goes down and the session is rehomed to a low speed link (GPRS, modem,
ADSL with limited uplink capacity). The send window used when the
session went along over the Gbps link will be so large that massive
congestion ensues, and also, all buffers will be filled up which
guarantuees that the congestion will persist for a relatively long
time, possibly a handful of seconds.
There are no easy answers here, but congestion control is one of the
core concerns in the development of the internet, so I don't think we
can get away with ignoring this completely.
i can see this is an issue...
what do you suggest to do here? could you send text?
o Preserve established communications in the presence of certain
classes of failures, for example, TCP connections and UDP
streams.
Shouldn't this be "communication"?
i don't think so...
it could be Preserve an established communication or Preserve
established communications
i think it is better the second one, because the first option seems we
are talking about a given specific communication...
o Have minimal impact on upper layer protocols in general and on
transport protocols in particular.
And applications.
ok
Early in the text, the phrase "site multihoming" is used. There has
been some discussion on this list as to whether shim6 actually is site
multihoming, and readers of the draft may not know that all of this is
the result of wgs chartered to work on "site" multihoming. So I
suggest adding text to clear up any potential confusion, for example:
"The shim protocol is a site multihoming solution in the sense that it
allows existing communication to continue when a site that has
multiple connections to the internet experiences an outage on a subset
of these connections or further upstream. However, shim processing is
performed in individual hosts rather than through site-wide
mechanisms."
ok will add this... did you have a place in the draft you were thinking
for this text?
Finally, this proposal also does not try to provide a new network
level or transport level identifier name space distinct from the
current IP address name space.
The terms "identifier" and "locator" are used extensively even though
the shim is NOT an actual identifier/locator separation solution...
Suggested text (immediately following the sentence above):
"The shim proposal doesn't fully separate the identifier and locator
functions that have traditionally been overloaded in the IP address.
However, throughout this document the term "identifier", or more
specifically, Upper Layer Identifier (ULID) refers to the identifying
function of an IPv6 address, and "locator" to the network layer
routing and forwarding properties of an IPv6 address."
ok will add that
solution. While this document doesn't specify all aspects of this,
it is believed that the approach can be extended to handle the non-
routable address case..
Extra period.
ok
(Note that the quaint custom of inserting an extra space after a
sentence is generally "discouraged" in style manuals.)
it is only after each paragraph, not after each sentence afaict
the original locators become invalid at the same time and depending
on the time that is required to update the DNS and for those updates
to propagate.
Why is the DNS relevant here?
because at least one valid locator must be published in the DNS in
order for a shim host to be reachable, since the DNS is used as a
rendez vous mechanism. OTOH, this is no specific of the shim6 protocol,
but generic for any host... do you prefer we remove the DNS
consideration from here?
But IP addresses are also used as ULID,
Addresses is plural, ULID singular... Probably make this "ULIDs".
ok
In the worst case we could end up with two separate hosts using the
same ULID while both of them are communicating with the same host.
This potential source for confusion is avoided requiring that any
communication using a ULID MUST be terminated when the ULID becomes
invalid (due to the underlying prefix becoming invalid).
This makes me uncomfortable. How do you know that an address has
become terminally invalid, rather than accidentally unusable?
this was discussed during the last meeting in san diego and there was
consensus that if a prefix is removed from the site, existing shim
contexts that are using a ulid containing the prefix must be terminated
when the prefix is removed.
however, i read from your comment is that you don't have a problem with
this idea but your problem is with how to implement this, right?
I contend that the distinction can't be made in a stack in a
meaningful way,
what about when the address becomes invalid?
so the above requirement will in practice only serve to disrupt
communication unnecessary. Rather, I would require some administrative
"cooling off" period to avoid using the same ULID by a different host
(only possible with CGA not HBA anyway). For instance, there must be
24 hours between decommisioning and recommisioning of address space,
and we garbage collect shim state after 24 hours of not being used.
but what do you mean the decomisioning of the prefix? wouldn't be this
the time the prefix is removed from the site? if this is so, the
current draft recommends that the existing shim6 contexts that are
using ulids containing this prefix are terminated
in other words, i fail to see why this is easier to implement that what
is currently in the draft. I mean, if the admin can determine the
decomisioning time, it also can terminate the existing shim6
contexts...
I don't see how regular nomadic behavior will result in two hosts
using the same address in quick succession, and they can further
reduce the potential for problems by not using temporary addresses as
ULIDs.
i am not sure what part of the draft this comment is referred to, but
if a nomadic host creates a ulid using a temporary prefix and it moves
away and then another nomadic hosts attaches itself to the same network
and generates the same address, it is possible that the the two nomadic
hosts end up using the same address. Now, it is worse a ULID collision
than a locator collision, in particular, beacause once the first
nomadic hosts leaves the visited network, the locator becomes
unreachable, so it cannot longer be used, even if the hosts wants to
use it. OTOH, if the address is being used as ulid, the first nomadic
host can keep on using it, even if it is no longer located in the
network from which it obtained the address. so i guess the comment
makes sense to me.
layer map to/from different locators. The shim6 layer maintains
state, called ULID-pair context, per ULID pairs
"Pairs" should probably be singular.
ok
fields, and even though those locators may be changed by the
transmitting shim6 layer. .
Extra .
ok
The result of this consistent mapping is that there is no impact on
the ULPs. In particular, there is no impact on pseudo-header
checksums and connection identification.
The problem here is that some intermediate system, such as a firewall
or a smart NIC, may take it upon itself to check the TCP or UDP
checksum and discard the packet if the checksum fails.
comments in a separate email
Inherent in a scalable multihoming mechanism that separates locators
from identifiers is that each host ends up with multiple locators.
This says explicitly that we do id/loc...
yes i can rephrase it using the id locator function terminology that
you suggested previously
This means that at least for initial contact, it is the remote peer
that needs to select which peer locator to try first. In the case
of
shim6 this is performed by applying RFC 3484 address selection.
This is incorrect: the application (or layer working on its behalf)
needs to select an initial ULID, which automatically becomes the
initial locator.
agree, will rephrase this
This document uses the terms MUST, SHOULD, RECOMMENDED, MAY, SHOULD
NOT and MUST NOT defined in RFC 2119 [1]. The terms defined in RFC
2460 [2] are also used.
Please list them.
ok, will try
FQDN Fully Qualified Domain Name
Hm, if you don't know what FQDN is you probably also don't know what
it is when spelled out... How about adding "full DNS name"?
i guess the goal here is just to describe the acronym, not to provide a
definition
document), such as having the ISPs relax there ingress filters, or
selecting the egress such that it matches the IP source address
prefix.
There -> their
ok
o Some heuristic on A or B (or both) determine that it is
appropriate to pay the shim6 overhead to make this host-to-host
communication robust against locator failures. For instance,
this
heuristic might be that more than 50 packets have been sent or
received, or a timer expiration while active packet exchange is
in
place. This makes the shim initiate the 4-way context
establishment exchange.
Maybe say something like:
"The purpose of this heuristic is to avoid setting up a shim context
when only a small number of packets is exchanged between two hosts."
ok, will add this
If the context establishment exchange fails, the initiator will
then know that the other end does not support shim6, and will
continue with standard unicast behavior for the session.
Unicast? Shouldn't this be "single homed"?
will change to standard (non-shim6) behaviour, ok?
the message allocated. Thus at a minimum the combination of <peer
ULID, local ULID, local context tag> have to uniquely identify one
context.
I'm not sure if I understand this.
More in general, the draft seems to suggest that the content of the
source address field in received packets may be ignored,
this is explicitly stated in the draft
actually the complete paragraph from where the sentence above belongs
to states:
A context between two hosts is actually a context between two
ULIDs.
The context is identified by a pair of context tags. Each end gets
to allocate a context tag, and once the context is established, most
shim6 control messages contain the context tag that the receiver of
the message allocated. Thus at a minimum the combination of <peer
ULID, local ULID, local context tag> have to uniquely identify one
context. But since the Payload extension headers are demultiplexed
without looking at the locators in the packet, the receiver will need
to allocate context tags that are unique for all its contexts. The
context tag is a 47-bit number (the largest which can fit in an
8-octet extension header).
as you can see, it is explicitly mentioned that the locators in the
packet are not used for demux and this is the assumption that is used
over the whole draft
actually, the first sentence of this paragraph where the uniqueness of
peer ulid, local ulid and context tag is required, is only included for
provide the context in which the design was performed. The actual
design choice that was made was that context tags are unique in a host.
have you identified other places of the draft where it is mentioned
that the demux is performed taking into account the locators in
addition of the context tag?
but also that this is not the case. This is a very important decision
with far reaching consequences so it should be made carefully. For
instance, if the source address may be rewritten arbitrarily,
obviously routers can easily do this without much or any coordination.
But the potential for security issues is significant in this case.
the security level provided by the shim6 protocol relies on the context
tag. Any attacker needs to learn the context tag before being able to
inject addresses into an established context. It was concluded that
this is an acceptable security level and similar to the one available
in today's internet... do you agree?
context. But since the Payload extension headers are demultiplexed
without looking at the locators in the packet, the receiver will
need
to allocate context tags that are unique for all its contexts.
See above.
context tag is a 47-bit number (the largest which can fit in an
8-octet extension header).
"while preserving one bit to differentiate the shim signalling
messages from the shim header included in data packets, allowing both
to use the same protocol number."
ok
4.2 context forking
Never been a fan of this, but it doesn't seem to add too much extra
complexity the way it is now.
fair enough...
Such discovery probably requires to be along the path in order to
be sniff the context tag value.
Grammar: clause without subject. Who is required to be along the path?
will rephrase
dynamic. For this reason there is a Update Request and Update
Acknowledgement messages, and a Locator List option.
Grammar. "is a" -> "are" would be better.
ok
Even when the list of locators is fixed, a host might determine that
some preferences might have changed. For instance, it might
determine that there is a locally visible failure that implies that
some locator(s) are no longer usable. This uses a Locator
Preferences option in the Update Request message.
I don't consider reachability status a preference...
the flags in the locator preference options, in particular the broken
flag is used for this. I may agree that this is not a preference, but
the other information which is related to this is preference and this
flag needed to be included somewhere and this seems the natural
place...
Bidirectional Communication (FBD). FBD uses a Keepalive message
which is sent when a host has received packets from its peer but has
not yet sent any packets from its ULP to the peer.
No, this works per address (per locator even, not per ULID, IIRC), not
per ULP.
the meaning here is that FBD generates packets when the ULPs are
silent. It doesn't mean that it generates packets per ULP, just that
when all ULPs are silent, FBD generates packets. It may be rephrased as
follows:
FBD uses a Keepalive message
which is sent when a host has received packets from its peer but has
not yet sent any packets from any of its ULPs to the peer.
would this be better?
which precedes a routing header). When tunneling is used, whether
IP-in-IP tunneling or the special form of tunneling that Mobile IPv6
uses (with Home Address Options and Routing header type 2), there is
a choice whether the shim applies inside the tunnel or outside the
tunnel, which affects the location of the shim6 header.
How is this coordinated with the other side? If one side does
tunneling first and shim second and the other side the other way
around, there will be trouble. I don't see an easy way to avoid this.
the header order would be enough imho. I mean, when tunneling is
performed, two IP layers are involved and each ip layer can have its
own shim sublayer inside. So, for each ip layer a shim header can be
added, so depending on the location of the shim header, how it applies,
makes sense?
the control messages; only the payload extension header use the Next
Header field.
uses
ok
Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59).
So what happens when some other header follows the shim header? Could
this be used for attacks?
this is for shim6 control messages and so far we haven't defined means
to perform piggybacking of other protocols in shim6 control messages,
so it is not possible for other protocols to follow the shim header. If
this is defined in future extensions, they will need to update this
part of the spec
About the different messages: they are very similar. If I were to
implement all of this, I would rather work with one basic structure
for all of the messages, even if the _meaning_ of some fields is
different as long as their structure is always the same. I think this
can easily be done here, by including fields that nearly all messages
need (simply leave it zero when a particular message doesn't need a
field) and use options for things that a particular message needs that
aren't accommodated in the unified structure.
i can clearly see the cost of this approach, additional overhead for
unused fields and potential source of confusion when fields change
their name... what is the advantage of such approach?
Did I miss the place where HBA information is exchanged?
The CGA Parameter data structure option contains all the information
required by the HBA
update request: why is this a request?
because this is a two way protocol, update and request... (i do agree
that it is not the best name in this case... suggestion?)
This message is sent in response to a Update Request message. It
implies that the Update Request has been received, and that any new
locators in the Update Request can now be used as the source
locators
of packets. But it does not imply that the (new) locators have been
verified to be used as a destination, since the host might defer the
verification of a locator until it sees a need to use a locator as
the destination.
Hm, is it smart to defer verification here?
depending what verification we are talking about....
this is explained in detail in section 7.2. Locator Verification
there are two type of verification HBA/CGA verification is one type and
the other type is the one against flooding attakcs that is achived
using a probe packets (of the path exploration protocol)
The spec in section 7.2 states that:
Thus the HBA/CGA
verification SHOULD be performed by the host before the host
acknowledges the new locator, by sending an Update Acknowledgement
message, or an R2 message.
Before a host can use a locator (different than the ULID) as the
destination locator it MUST perform the HBA/CGA verification if this
was not performed before upon the reception of the locator set. In
addition, it MUST verify that the ULID is indeed present at that
locator. This verification is performed by doing a return-
routability test as part of the Probe sub-protocol [9].
makes sense?
We've already said that the other end may use them as source
addresses. If there is a failure and we do the verification then, we
may find out that it fails and we have no reasonable course of action.
Also, for CGA verification, don't we need to send the other side a
challenge to avoid replays?
separate email for this issue
direction. When the ULP is sending bidirectional traffic, no extra
packets need to be inserted.
This works per address pair, not per ULP.
this is similar to what we were discussing above...
the ulps are the one sending traffic... maybe we can rephrase it as:
When the traffic generated by the ULPs results in a bidirectional flow
of packet between the peers, no extra packets need to be inserted.
is this ok?
5.13. Probe Message Format
This message and its semantics are defined in [9].
The idea behind that mechanism is to be able to handle the case when
one locator pair works in from A to B, and another locator pair
works
from B to A, but there is no locator pair which works in both
directions. The protocol mechanism is that as A is sending probe
messages to B, B will observe which locator pairs it has received
from and report that back in probe messages it is sending to A.
No, this is to test whether locator pairs work or not in the general
case.
agree, we went on describing the details without previously describing
the main idea...
we can add your sentence at the begining of the paragraph, resulting in:
The goal of this mechanism is to test whether locator pairs work or
not in the general case. In particular, this mechanism is able to
handle the case when
one locator pair works in from A to B, and another locator pair works
from B to A, but there is no locator pair which works in both
directions. The protocol mechanism is that as A is sending probe
messages to B, B will observe which locator pairs it has received
from and report that back in probe messages it is sending to A.
would this be ok?
All of the TLV parameters have a length (including Type and Length
fields) which is a multiple of 8 bytes.
Ugh, this is certainly enough to make a grown man cry... Why all of
this alignment silliness? BGP works pretty well without it.
i think this is general in IPv6 protocols which are optimized for
handling 64 bits units.... but maybe someone with more expertise can
answer this one...
Consequently, the Length field indicates the length of the Contents
field (in bytes). The total length of the TLV parameter (including
Type, Length, Contents, and Padding) is related to the Length field
according to the following formula:
Total Length = 11 + Length - (Length + 3) % 8;
This is almost impossible to understand.
First of all, this assumes familiarity with C or a similar language
from the reader to note that % is the modulo operation and that it
binds stronger than subtraction. As such, this would be an
improvement:
Total Length = 11 + Length - ((Length + 3) mod 8)
ok
However, the logic that underpins this is never spelled out, apart
from the requirement that all options be a multiple of 8 bytes long.
(Yes, _bytes_, not octets.)
Text:
"The Total Length of the option is the smallest multiple of 8 bytes
that allows for the 4 bytes of option header and the option itself.
The amount of padding required can be calculated as follows:
padding = 7 - ((Length + 3) mod 8)
And:
Total Length = 4 + Length + padding"
great, thanks!!
will add this
I see no discussion of size issues. A single option can be made large
enough to push a packet beyond 1280 bytes. More realistically, this
will happen when multiple options are present. What happens in this
case? What is the largest option size and the largest shim packet size
implementations must be prepared to handle?
separate email for this
C: Critical. One if this parameter is critical, and
MUST
be recognized by the recipient, zero otherwise.
You can't force a receiver to recognize something...
in general, i think this means that if this bit is set and the receiver
don't understand the content, then it must react accordingly. If not
critical, it simply silently ignore the option
i can rephrase it to express this....
o If C=1 then the host SHOULD send back an ICMP parameter problem
(type 4, code 1), with the Pointer referencing the first octet in
the option Type field. When C=1 the message MUST NOT be
processed.
Why use ICMP for errors? Isn't it easier to define a shim error
message?
If the correspondent wants to fall back to some other way to set up
the shim having to intercept ICMP messages to make that happen is
pretty messy.
More in general, most error conditions are handled by silently
dropping packets, however, which is a very bad idea because that way,
there is no difference between an error and lost messages.
So in some cases, a host may continue to resend the offending packet
because it doesn't know something went wrong. The main problem with
this approach is that you can't debug it from one end: you need to see
what happens on both ends to determine why something doesn't work.
Silently dropping packets because of errors is the right approach for
security reasons in some cases, but I don't think this applies here. A
short error message with an error code and optionally a human-readable
message would be much better. As long as these error packets are
smaller than the packets that trigger them, there should be little or
no security impact, especially considering that we're prepared to talk
shim with the correspondent in question to begin with.
sent this issue in a separate email
The responder can choose exactly what input is used to compute the
validator, and what one-way function (MD5, SHA1)
Or something else, I presume? So "(such as MD5 or SHA-1)"
ok
About the locator option: how many locators are allowed?
there is no upper limit other than the ones that fit inside a packet
with the other required options... As i mentioned above, roughly this
seemed enough not to become a limitation
TEMPORARY: 0x02
The intent of the BROKEN flag is to inform the peer that a given
locator is known to be not working. The intent of TEMPORARY is to
allow the distinction between more stable addresses and less stable
addresses when shim6 is combined with IP mobility, when we might
have
more stable home locators, and less stable care-of-locators.
So this has nothing to do with RFC 3041 temporary addresses?
right
In that case, a different name is probably better.
agree... what about "transient"?
o For each peer locator, a bit whether it has been verified using
HBA or CGA, and a bit whether the locator has been probed to
verify that the ULID is present at that location.
"Flag" rather than "bit"?
no preference here, so flag if you find it clearer
| E-FAILED | Context establishment exchange failed
How do we know this,
becuase we have retried several times with I1 and never got a R1 back
and is it necessary to explicitly take notice of this situation?
yes, so we don't try again for a while
makes sense?
| E-FAILED | ULID(peer), ULID(local)
|
| |
|
| NO-SUPPORT | ULID(peer), ULID(local)
How is ULID(local) relevant here?
because we have tried to establish a shim6 context for a given ULID
pair.
We know there is connectivity (ULP is running)
this is not necesarily the case, we can try to establish the shim6
context without having an ongoing ulp communication
so if we don't get any shim negotation back or it fails, then this
situation can be attributed to the peer as a whole, not to the ULID
pair.
agree, but you don't know what are all the ULIDs of the peer, so i
guess that at this point, caching that a shim6 context establishment
exchange has failed for this ULID pair is the best you can do at this
point...
In all the cases the result is that the peer without state receives
a
shim message for which it has to context for the context tag.
To -> no?
ok
case we can not use the recovery mechanisms since there needs to be
separate context tags for the two ULID pairs.
Needs -> need
ok
Regarding section 7.9: shouldn't there be checks to make sure that
seemingly duplicate packets contain the same information as the
earlier packets they are supposedly the duplicate of?
I am not following you here...
are we talking about an initiator that receives a duplicate R1 back or
a receiver that receives a duplicate I1?
If a receiver receives a duplicate I1 it doesn't do anything special,
just replies with a R1. don't see any problem here
If an initiator receives a duplicated R1 (this may be due that the
initiator have retried with multiple I1), it will process the first one
received, and send a I2. The second one received, there will be no
shim6 context in I1-SENT state, so it will be discarded. I do not see
the point in verifying that the other information in the packet is ok
or not... what would be the point in doing this verification?
What if validators don't match? Eventually this shouldn't be a problem
but I expect some initial trouble here because you're doing hashes
over a fairly large number of values, a small mistake somewhere means
the hash doesn't work, some feedback in the form of an error message
would be good.
you mean for the first packet or for the following (duplicated)
packets? for the first packet, this is a specific case of the general
problem about whether it is ok to silently discard wrong packets (that
i have initiated a new thread for this)
For the second case, i don't see any point on doing this...
It occurs to me that there is nothing or very little in the protocol
that precludes shim negotiation using non-ULID addresses.
not sure what you mean by non ulid addresses....
We probably need a few minor tweaks to the reachability protocol to
also allow this, but then there is no fundamental reason to not allow
shim setup using non-ULID addresses, and by extension, unreachable
ULIDs = a separate identifier space.
if you mean that the shim protocol can support unreachable ULIDs like
ULAs, then the answer is yes, it has been taken into account and should
work fine with unreachable ulids...(you cannot do deferred setup but
the spec supports it)
If it's this easy, we should definately make sure there isn't some
minor obstacle somewhere,
this has been done, and i hope there are no obstacles. If you have
identified some, please let me know
so that we can add this feature easily in the future when we've
worked out the additional issues such as locator discovery.
o Where Ls(peer) has at least one locator in common with the newly
created or updated context.
Why? I don't see how that buys us anything. Also, it's fairly trivial
to insert a bogus locator to meet the requirement that there is one in
common between the old and new sets.
this is not a security check. The goal of this verification is to find
out whether we are in the context confusion situation i.e. if we have a
single peer that is using the same context tag value for two different
contexts. We can identify this situation because of the overlapping of
at least one locator in the locator set (this means it is the same host
in both contexts)
Adn why verify whether the source address is in Ls(peer)? The security
mechanisms do all the checking we need.
could you point me where is the text you are referring to? i mean there
is no such verification in section 7.15 which was the section the
previous comment was referring to...
context. In this case, we are in the Context confusion
situation,
and the host MUST NOT use the old context to send any packets.
It
MAY just discard the old context (after all, the peer has
discarded it), or it MAY attempt to re-establish the old context
by sending a new I1 message and moving its state to I1-SENT. In
any case, once that this situation is detected, the host MUST NOT
keep two contexts with overlapping Ls(peer) locator sets and the
same context tag in ESTABLISHED state, since this would result in
demultiplexing problems on the peer.
What if an attacker is trying to interfere with legitimate
communication? We must be VERY sure that the new shim messages come
from the same host as the one that created the existing state if we're
going to mess with that existing state.
separate email for this
About the randomness of the context tag: I don't think we have to
require that the entire context tag random in a cryptographically
strong sense. If this makes implementation easier, why not allow an
implementation to use part of the CT to be used as a lookup key (which
is relatively easy to predict) as long as enough bits are really
random? In my opinion, 20 good random bits is enough here. Suggested
text (but no suggested place to put it):
"It is important that context tags are hard to guess for off-path
attackers. Therefore, if an implementation uses structure in the
context tag to facilitate efficient lookups, at least 20 bits of the
context tag must be unstructured and populated by completely random
bits. For this purpose, bits derived from one of the generally used
one-way hash functions such as SHA-1 may be considered random.
yes, structure in context tags can be useful for other purposes as
well, so i think your recomendation is ok
A host MUST silently discard any received Update Acknowledgement
messages that do not satisfy all of the following validity checks in
addition to those specified in Section 12.2:
o The Hdr Ext Len field is at least 1, i.e., the length is at least
16 octets.
Added bonus when the header structure is unified: no need to repeat
the above over and over throughout the text.
NO_R1_HOLDDOWN_TIME = 1 min
ICMP_HOLDDOWN_TIME = 10 min
This seems rather short, basically a shim host talking to a non-shim
host would retry setting up the shim every minute or every 10 minutes
even though there is good reason to assume this won't be successful.
Something like several hours seems more appropriate. (And only when
packets are actively exchanged.)
well, NO_R1_HOLDDOWN_TIME is about how long we should wait until we
retry when no R1 have been received. Note that this may be due to
network outages that can be solved in a short time. So, we have a good
reason to assume this will be successful, someone fixed the network
path :-)
in the other case, i agree, what about:
NO_R1_HOLDDOWN_TIME = 5 min
ICMP_HOLDDOWN_TIME = 60 min
network transit path. Second, in case that IPSec is implemented as
Bump-In-The-Wire (BITW) [7] it is expected that the shim6 sub-layer
is also implemnted in the same fashion.
Not strong enough:
"in case that IPSec is implemented as Bump-In-The-Wire (BITW) [7],
either the shim MUST be disabled, or the shim MUST also be implemented
as Bump-In-The-Wire, in order to satisfy the requirement that IPsec is
layered above the shim."
ok
could require a 2-way handshake "did you really loose the state?"
in response to the error message.
lose
ok
o The validator included in the R1 and R1bis packets are generated
as a hash of several input parameters. However, most of the
inputs are actually determined by the sender, and only the secret
value S is unknown to the sender. However, the resulting
protection is deemed to be enough since it would be easier for
the
attacker to just obtain a new validator sending a I1 packet than
performing all the computations required to determine the secret
S. However, it is recommended that the host changes the secret S
periodically.
Too many howevers...
will try to rephrase
o Study whether a host explicitly fail communication when a ULID
becomes invalid (based on RFC 2462 lifetimes or DHCPv6), or
should
we let the communication continue using the invalidated ULID (it
can certainly work since other locators will be used).
Some kind of grammar problem, not obvious to me what is meant here.
we have discussed this problem and already agreed on terminating the
communication, so i will remove this paragrpah
Appendix B. Simplified State Machine
The states are defined in Section 6.2. The intent is that the
stylized description below be consistent with the textual
description
in the specification, but should they conflict, the textual
description is normative.
Haven't looked at this.
that the Flow Label carries context information as proposed in the
now expired NOID draft. .
Extra .
ok
It may happen, that later on, one of the hosts, e.g. Host A looses
the shim context.
loses
ok
Mechanisms for detecting context. loss
Extra word?
Mechanisms for detecting context loss.
:-)
There are discussions in the appendixes, maybe make this a separate
document?
i am ok either way....
The Locator List Option Format only specifies two verification methods
at this time: CGA or HBA. What about the case where a locator can be
verified using either CGA or HBA? Maybe it makes more sense to have
each method be a bit so they can be present or absent independently.
if this turns to be useful we could define a verification code that
would be CGA or HBA but i don't see why this would be useful... do you?
approach eliminates the possibility of a context confusion situation
because premature garbage collection, but it does not prevents
prevent
ok
[9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
Exploration Protocol for IPv6 Multihoming",
Please make this "I. van Beijnum"
will try if the xml tool allows me to....
Note to self: look at implications of the fact that keepalive and
probe messages (as defined here) don't trigger R1bis in the
reachability draft.