[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
about draft-ietf-shim6-proto-01.txt
Hi,
i think that the document is improving rapidly, i send some comments
below...
In section 1.6 Placement of the shim
The proposal uses an multihoming shim layer within the IP layer,
i.e., below the ULPs, as shown in Figure 1, in order to provide ULP
independence. The multihoming shim layer behaves as if it is
associated with an extension header, which would be ordered
immediately after any hop-by-hop options in the packet.
the shim header is placed after the routing header (and the associated
destination options header) rather than immediately after than the
hop-by-hop header (as mentioned in section 5.1)
In section 2.1 Definitions
Host-pair context The state that the multihoming shim maintains for
a particular peer. The context is for a ULID
pair, as is identified by a context tag for each
direction.
I would rather use the expression shim-context rather than host pair
context, because since each context is associated to a given ULID pair,
there maybe more than one context for a given host pair, right?
(moreover, as we consider the forking concept more in depth, there
maybe more than one context for a given ulid pair) so using the vague
expression shim context would suit to whatever extent this evolves to.
Similarly, i wouldn't say that the Host-pair context is" The state that
the multihoming shim maintains for a particular peer." but rather that
it is the "The state that the multihoming shim maintains for a
particular ULID pair." (at least for now)
In section 4.1 Context Tags
The mechanism for detecting a loss of context state at the peer that
is currently proposed in this document assumes that the receiver can
tell the packets that need locator rewriting, even after it has lost
all state (e.g., due to a crash followed by a reboot).
I would then add that this is achieved because after a rehoming event
packets that need locator rewriting carry the Payload Message Header
Even though we do not overload the flow label field to carry the
context tag, any protocol (such as RSVP or NSIS) which signals
information about flows from the host stack to devices in the path,
need to be made aware of the locator agility introduced by a layer 3
shim, so that the signaling can be performed for the locator pairs
that are currently being used.
I would remove the first part of the sentence of this paragraph. I
mean, in the future when people read the spec, they won't be familiar
with our flow label discussions, so this initial part of the sentence
may sound a bit strange to them imho.
In section 5. Message Formats
I find the separation between the payload and control messages not
really clarifying.
I mean the first paragraph in section 5 states that:
The shim6 messages are all carried using a new IP protocol number TBD
[to be assigned by IANA]. The shim6 messages have a common header,
defined below, with some fixed fields, followed by type specific
fields.
However, this common header is not presented, but instead, the payload
message header and the common shim control header (which are different)
are presented. (including this flag which changes from 0 in control
messages to 1 in payload messages but that is not described explicitly
in the doc)
I guess that the common shim header would be the following:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
being P a flag that indicates whether this is a payload message (P set)
or this is a control message (P reset)
and then the payload and control messages can be defined.
Then in section 5.2 Common Shim6 Control header
The common part of the header has a next header and header extension
length field which is consistent with the other IPv6 extension
headers, even if the next header value is always "NO NEXT HEADER" for
the control messages
but before this header there can be other header, right? like the
routing header or hop-by-hop header.
My point is that this header is also located before
any endpoint extension headers (fragmentation headers, destination
options header, AH, ESP), but after any routing related headers (hop-
by-hop extensions header, routing header, a destinations options
header which precedes a routing header).
The difference is that for now, no piggybacking of ulp in the shim
control messages is defined yet.
So i would state the location of the shim header and distinguish the
case of payload messages where piggybacking of ulp is supported and
control messages, where it is not.
This description would fit in the description of the common header
(since it is always placed in the same place)
In section 5.4 R1 Message Format
It may make sense to allow the responder to include the locator set in
the R1 message, so that the initiator can acknowledge the reception of
the locator set (otherwise, the locator set of the responder is sent in
R2 which remains unacknowledged).
the potential problem with this is that an small I1 packet may result
in a somehow big R1 packet which may be used by an attacker as an
amplifier (but i am not sure whether this is a big issue, since the
amplification won't be so important)
In section 5.6 R2 Message Format
CGA Parameter Data Structure: Included when the locator list is
included and the PDS was not included in the context
establishment messages, so the receiver can verify the
locator list.
This is kind of strange since this is one of the context establishment
messages...
I guess it should read the same than in I2, i.e.
CGA Parameter Data Structure: Included when the locator list is
included so the receiver can verify the locator list.
In section 5.8 Update Request Message Format
As i understand the locator set contained in this message contains the
complete set of locators available, as opposed to including a
differential list of what are the new locators to be added/removed to
the locator list, right?
If this is so, i think this should be explicitly stated in this section.
In section 5.9 Update Acknowledgement Message Format
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
I am not sure what verifications are needed to accept a new locator as
a valid src address and which is needed for using it as a valid dst
address.
I mean, i clearly see that the reachability test used to prevent
flooding attacks is required before using the new locator as dest
address, but it is not needed before accepting packets with this
locator as src address. But, are the HBA/CGA verifications required
before accepting packets with the new locator as src address? In other
words, does the receiver of a update request message needs to perform
HBA/CGA validation before sending the update ack packet?
Let's see this a bit more in detail... accepting packets from
unverified locators in src address would allow an attacker to inject
packets in a communication associated with a shim context, even though
the peer will be still sending packets to the verified address. Of
course for doing that, the attacker needs to determine the context tag,
so it needs to have been on path once (and also need to use a sequence
number in the locator update higher than the one currently used), so it
doesn't seems so easy. However, accepting an unverified locator set may
cause problems, in particular suppose that the attacker sends a packet
with a very high seq number and the correct context tag, but it
includes a locator list that contains all invalid locators. The victim
accepts the list and substitutes the old (valid) list by the new
(false) list. The result is a DoS attack, since there won't be any
locator valid in the new list. Basically, accepting unverified lists of
locators would enable time-shifted DoS attacks. This can be prevented
by performing hba/cga verification before accepting the locator list.
This has a cost though, since we need to make all the computation
effort of verifying the locator list upon the reception of the list,
even if we may not need the alternative locators ever.
In section 5.10 Reachability Probe Message Format
This message includes the ULID pair as well as the context tag, so
that the peer can indeed verify that it has that ULID and that the
context tag is correct.
Just to keep in mind Iljitsch suggestion to be able to use a single
reachability probe when multiple contexts were using the same locator
pair, so that no multiple probes to the same locator pair are needed.
For this, we need something different than simply the context tag and
the ulid pair. Perhaps all the ulids and context tags of the involved
context would be enough rather then move to new namespaces as
hostids...
In section 5.14 Option Formats
it is stated that:
Total Length = 11 + Length - (Length + 3) % 8;
wouldn't that be
Total Length = 12 + Length - (Length + 4) % 8;
I mean, the length of the content of the option plus the type and
length fields is: Length + 4, right?
so the padding needed is 8 - ((length + 4) Mod 8)
implying a total length of 12 + Length - (Length + 4) % 8... what did i
got wrong?
In section 5.14.1 Validator Option Format
wouldn't it make sense to define different option types for different
hash functions used for the validator? like 1 for sha1 validator, 2 for
md5 and so on, so that different hash functions are supported? (and it
is possible to move from one to another hash function by supporting
many of them?
In section 5.14.3 Locator Preferences Option Format
I am not sure i fully understand the format of this option...
For instance, all elements have the same length i.e. the Element length
field message applies to all the elements, or there is an Element
Length field for each Element item that follows? (i think it is the
first option, but the figure confuses me, because the Element[2] seems
to have a different Length than Element[1] and Element[3]; other thing
that confuses me about the figure is that the Element Length field
seems to have variable length or 2 octets (because it has two rows))
In section 5.14.4 CGA Parameter Data Structure Option Format
CGA Parameter Data Structure: Variable length content. Content
defined in [5].
the format of the PDS is defined in RFC3972 and only the multiprefix
extension is defined in [5]
In section 5.14.5 CGA Signature Option Format
CGA Signature: Variable length content. Content defined in [5].
The format of the CGA signature is defined in RFC3972. Besides, the
signature defined in RFC3972 requires a 128-bit type tag for the
message from the CGA Message Type name space that is specific to the
usage of the CGA. In this case we would need to define such for shim
and declare it in the IANA considerations, so that IANA assigns it.
This 128 bit type tag is concatenated to what is being signed, so i
guess this needs to be included here.
Furthermore, i guess we need to specify what is being signed here. I
guess it doesn't makes sense to sign the whole locator list, since some
of them are validated using HBAs. So a possible approach would be to
extract from the locator list all of those that are validated through
the CGA and sign those (ordered as they are included in the locator
list),
So the string being signed would be:
the 128-bit type tag for the message from the CGA Message Type name
space assigned to the shim plus that ordered list of locators that are
validated using the CGA as they appear in the locator list of the
update request message
In section 6.1 Conceptual Data Structures
o For each peer locator, a bit whether it has been validated using
HBA,
i would add here "or CGA"
Moreover, perhaps we need a byte to indicate the validation method
consistent with what is defined in the locator list option format
In section 7.5 Sending I1 messages
If, after several retransmissions, there is no response, then most
likely the peer does not implement the shim6 protocol, or there could
be a firewall that blocks the protocol.
I guess that this depends on whether there is an ongoing communication
or not. If there is an ongoing communication, then we can assume that
the ulid is reachable, so if no answer is received then is because of
any of the two above reasons. However, if there is not an ongoing
communication or if a failure has just occurred, maybe it is that the
ULID selected in unreachable and other locators/ULIDs should be tried.
Not sure what to do in this case...
In section 9. Handling ICMP Error Messages
But when the shim on the transmitting side
replaces the ULIDs in the IP address fields with some other locators,
then an ICMP error coming back will have a "packet in error" which is
not a packet that the ULP sent. Thus the implementation will have to
apply the reverse mapping to the "packet in error" before passing the
ICMP error up to the ULP.
but the ICMP error won't have a shim payload header so, it won't be
processed by the shim, right? or are we supposing that thee shim will
inspect all packets (having the shim header or not) and identify ICMP
error packets and in those inspect whther the inside packet contains a
shim header and then do the processing?
I am especially concerned with the inspect all packets part, since i
think i remeber talking in the meeting that this would result in
important performance issues...
10. Teardown of the Host Pair Context
Each host can unilaterally decide when to tear down a host-pair
context. It is RECOMMENDED that hosts not tear down the context when
they know that there is some upper layer protocol that might use the
context.
Not sure i agree here. I recall Iljitsch suggestion that servers could
tear down context prematurelly and leave up to the clients the recovery
effort, using the context loss recovery mechanisms in order to reduce
the load imposed by the shim. This sounds like a very nice approach to
me. so i am not sure i agree with the reccomend here (perhaps i fail to
see what the reccomend term implies...
Section 16. Open Issues
The following open issues are known:
o Is there need for keeping the list of locators private between the
two communicating endpoints? We can potentially accomplish that
when using CGA but not with HBA, but it comes at the cost of doing
some public key encryption and decryption operations as part of
the context establishment.
I think that the option selected for this is a future extension of the
protocol
o Forking the context state. On the mailing list we've discussed
the need to fork the context state, so that different ULP streams
can be sent using different locator pairs. No protocol extensions
are needed if any forking is done independently by each endpoint.
But if we want A to be able to tell B that certain traffic (a
5-tuple?) should be forked, then we need a way to convey this in
the shim6 protocol. The hard part would be defining what
selectors can be specified for the filter which determines which
traffic uses which of the forks. So the question is whether we
really need signaling for forking, or whether it is sufficient to
allow each endpoint to do its own selection of which locator pair
it is using for which traffic.
imho for this what is needed is the capability of setting multiple
context with the same ULID pair but with different context tags, and an
API that allows the ulp to signal the shim which context is to be used
(what the doc calls primary vs other contexts i think)
o If we allow forking, it seems like the mechanism for reachability
detection, whether it is CUD or FBD, must be applied separately
for each locator pair that is in use. Without forking a single
locator pair will be in use for each host-pair context, hence
things would be simpler.
right, but this is a natural concequence, because we have multiple
contexts now
o The specified mechanism (of relying on No Such Context errors)
doesn't always detect the loss of the context on the peer when the
original ULID=locators are used. See Section 17 for other
options.
since we are using the reactive strategy that allows the node to
rcreate a shim state even after one end has lost it, then the only
issue here is performance
o In the Locator List option, do we need to indicate which locators
need to be validated using HBA vs. CGA? Or it could tell which
locators are in the HBA extension in the PDS, and assume any
others need CGA validation.
the spec indicates which validation option is used for each, which is a
good approach imho
20. IANA Considerations
a CGA Message Type needs to be allocated for shim
Editorial
In the Abstract
The SHIM6 working group is exploring a layer 3 shim approach for
providing locator agility below the transport protocols, so that
multihoming can be provided for IPv6 with failover and load spreading
properties, without assuming that a multihomed site will have a
provider independent IPv6 address which is announced in the global
IPv6 routing table.
i would say "provider independent IPv6 address block" or "provider
independent IPv6 address prefix"
In section 1.6 Placement of the shim
Thus, effectively the
multihoming shim layer is placed between the IP endpoint sublayer,
which handles fragmentation, reassembly, and IPsec, and the IP
routing sublayer, which on a host selects which default router to use
etc.
s/which on/on which
In 2.1 Definitions
i would suggest to leave a blank line between each definition to
improve readability
address An IP layer name that contains both topological
significance and acts as a unique identifier for
an interface. 128 bits. This document only uses
the "address" term in the case where it isn't
specific whether it is a locator or a identifier.
s/a identifier/an identifier
upper-layer identifier (ULID)
An IP locator which has been selected for
communication with a peer to be used by the upper
layer protocol.
i would prefer to say that the ulid is an address rather than a locator
(seems clearer to me, and in the next paragraph is stated that in this
case the ulid is also a valid locator)
Current locator pair Each end of the context has a current locator
pair which is used to send packets to be peer.
The two ends might use different locator pairs
though.
s/The two ends might use different locator pairs/The two ends might use
different current locator pairs
in section 4.1 Context Tags
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, the
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 MUST uniquely identify one
context.
s/local context> tag/local context tag>
in section 6.1 Conceptual Data Structures
The key conceptual data structure for the shim6 protocol is the host
pair context. This is a data structures which contains the following
information:
s/structures/structure
in section 7.3 Context recovery
This need can arise in two cases:
The communication is working using the ULID pair as the locator
pair, but a problem arises, and the end that has retained the
context state decides to explore alternate locator pairs.
The communication is working using a locator pair that is not the
ULID pair, hence the ULP packets sent from a peer that has
retained the context state use the shim payload header.
I guess it would improve readability to include a this as a bulleted
list (or a bank line separating the two items)
In section 7.4 Context confusion
This type of "confusion" can be observed in two cases (assuming it is
A that has retained the state and B has dropped it):
B decides to create a context for ULID pair <A3, B1>, and
allocates X as its context tag for this, and sends an I1 to A.
A decides to create a context for ULID pair <A3, B1>, and starts
the exchange by sending I1 to B. When B receives the I2 message,
it allocates X as the context tag for this context.
In both cases, A can detect that B has allocated X for ULID pair <A3,
B1> even though that A still X as CT(peer) for ULID pair <A1,
B1>. Thus A can detect that B must have lost the context for <A1,
B1>.
s/>/>
besides, putting the two cases in a bulleted list would be clearer imho
7.7 Receiving R1 messages
When the host receives an R1 message, it verifies that the nonce
matches what it sent in the I1 message, and that it has context state
for the ULID pair. It then sends an I2 message, which includes the
verifier option that was in the R1 message. The I2 message also
includes A's locator list and the CGA parameter set.
s/CGA parameter set/CGA parameter data structure
If CGA (and not
HBA) is used to verify the locator list, then A also signs things and
includes a CGA signature option.
sign "things" is maybe a bit too colloquial perhaps...