[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Changes in version 8 resulting from: Re: shim6-proto-07 review
Hi,
these are the changes that i am including in version 8 of the draft
based on the comments made in this review.
(besides thos that i have addressed in separate emails)
El 11/12/2006, a las 19:54, Iljitsch van Beijnum escribió:
o Have minimal impact on upper layer protocols in general and on
transport protocols in particular.
And applications.
done
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."
added in the introduction
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."
added the paragraph in the suggested place
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. (Note that the quaint custom of inserting an extra space
after a sentence is generally "discouraged" in style manuals.)
removed extra period
But IP addresses are also used as ULID,
Addresses is plural, ULID singular... Probably make this "ULIDs".
done
layer map to/from different locators. The shim6 layer maintains
state, called ULID-pair context, per ULID pairs
"Pairs" should probably be singular.
done
fields, and even though those locators may be changed by the
transmitting shim6 layer. .
Extra .
done
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...
rephrased as
Inherent in a scalable multihoming mechanism that separates the locator
function of the IP address from
identifying function of the IP address is that each host ends up with
multiple locators.
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 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.
rephrased as
This means that at least for initial contact, it is the remote peer
application
(or layer working on its behalf) needs to select an initial ULID,
which automatically becomes the initial locator. In the case of Shim6
this
is performed by applying RFC 3484 address selection.
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
done
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."
added the above sentence in the suggested place
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"?
changed to standard (non-shim6) behaviour
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."
added
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?
rephrased as
Such discovery probably requires any potential attacker to be along the
path in order to be sniff the context tag value. The result
is that through this technique, the Shim6 protocol is
protected against off-path attackers.
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.
done
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.
rephrased as
The goal of this mechanism is to test whether locator pairs work or
not in the general case. In particular, this 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.
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)
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"
added the suggest text and modifications
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)"
done
About the locator option: how many locators are allowed?
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? In that
case, a different name is probably better.
changed the name of TEMPORATY flag to TRANSIENT flag
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"?
changed to flag
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?
changed
case we can not use the recovery mechanisms since there needs to be
separate context tags for the two ULID pairs.
Needs -> need
done
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.
added the text in section Uniqueness of Context Tags, resulting in:
<section title="Uniqueness of Context Tags" anchor="context-tag">
<t>As part of establishing a new context, each host has to assign a
unique
context tag. Since the Payload Extension headers are demultiplexed based
solely on the context tag value (without using the locators), the
context
tag MUST be unique for each context.
</t>
<t>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 30 bits of the context tag MUST
be
unstructured and populated by completely random bits.</t>
<t>In addition, in order to minimize the reuse of context tags, the host
SHOULD
randomly cycle through the unstrucutred tag name space reserved
for randomly assigned context tag values,(e.g. following the
guidelines described in <xref target='RFC4086'/>).</t>
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."
done
could require a 2-way handshake "did you really loose the state?"
in response to the error message.
lose
done
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...
agree
rephrased as
<t> The validator included in the R1 and R1bis packets are generated
as a hash of several input parameters. While most of the inputs are
actually determined by the sender, and only the secret value S is
unknown
to the sender, 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. Nevertheless, it is recommended
that the host
changes the secret S periodically.
</t>
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.
removed the paragraph
that the Flow Label carries context information as proposed in the
now expired NOID draft. .
Extra .
removed
It may happen, that later on, one of the hosts, e.g. Host A looses
the shim context.
loses
done
Mechanisms for detecting context. loss
Extra word?
done
approach eliminates the possibility of a context confusion situation
because premature garbage collection, but it does not prevents
prevent
done
[9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
Exploration Protocol for IPv6 Multihoming",
Please make this "I. van Beijnum"
will try, but note that the reference in the xml directory is imported
this way
Let me know about any issue about the comments addressed in this email
I will send a separate email with open issues from this review
thanks again for the review
Regards, marcelo