[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-ietf-shim6-proto-03
Hello,
Let me post my comments on draft-ietf-shim6-proto-03. I have not read
the whole document yet, but here are my comments/questions from Section
1 to Section 14. Some are editorial, some are technical. I will
continue to read rest of the document and send more comments later.
From 1.1 Goals:
> The goals for this approach is to:
>
> o Preserve established communications through failures, for example,
> TCP connections and application communications using UDP.
>
> o Have no impact on upper layer protocols in general and on
> transport protocols in particular.
>
> o Address the security threats in [20] through a separate document
> [7], and techniques described in this document.
>
> o No extra roundtrip for setup; deferred setup.
I am not sure what does the above (fourth) bullet mean. Does
"deferred setup" mean context establishment follows the IP transaction
based on the ULID pair ?
>
> o Take advantage of multiple locators/addresses for load spreading
> so that different sets of communication to a host (e.g., different
> connections) might use different locators of the host. This might
> enable some forms of traffic engineering, but the details for
> traffic engineering, including what requirements can be satisfied,
> have not yet been worked out.
>
I am not sure if there is semantic difference between "load balancing"
and "load spreading", but the former sounds more familiar to me.
> 1.4 IP Multicast
>
> IP Multicast requires that the IP source address field contain a
> topologically correct locator for interface that is used to send the
> packet, since IP multicast routing uses both the source address and
> the destination group to determine where to forward the packet.
> (This isn't much different than the situation with widely implemented
> ingress filtering [11] for unicast.)
>
> While in theory it would be possible to apply the shim re-mapping of
> the IP address fields between ULIDs and locators, the fact that all
> the multicast receivers would need to know the mapping to perform,
> makes such an approach difficult in practice. Thus it makes sense to
> have multicast ULPs operate directly on locators and not use the
> shim. This is quite a natural fit for protocols which use RTP [15],
> since RTP already has an explicit identifier in the form of the SSRC
> field in the RTP headers. Thus the actual IP address fields are not
> important to the application.
>
> In summary, IP multicast will not use the shim to remap the IP
> addresses.
Section 1.4 talks about relation to IP Multicast as above. While I
agree that applying SHIM6 to the sender of IP Multicast does not seem
reasonable (in a sense that it requires sender to establish context
with all the receivers, which is unrealistic) it might be worth taking
a look at applicability of SHIM6 to the receiver node. As typical
scenario of IP multicast would be that the sender node is stationary
and receiver spreads in the network. It is more likely that receiver
changes its locator frequently than sender.
> 1.5 Renumbering Implications
...
[snip]
...
> However, terminating the communication might be overkill. Even when
> an IPv6 prefix is retired and reassigned to some other site, there is
> a very small probability that another host in that site picks the
> same 128 bit address (whether using DHCPv6, stateless address
> autoconfiguration, or picking a random interface ID [12]). Should
> the identical address be used by another host, then there still
> wouldn't be a problem until that host attempts to communicate with
> the same peer host with which the initial user of the IPv6 address
> was communicating.
>
> The protocol as specified in this document does not perform any
> action when an address becomes invalid. As we gain further
> understanding of the practical impact of renumbering this might
> change in a future version of the protocol.
In general, I agree with what is stated in Section 1.5 about renumbering
implications. Particularly, we should consider how a host treats the
ULID which becomes unavailable. In such case, at least the ULID should
be removed from the physical interface and marked as
"still-in-use-but-to-be-soon-removed." The active connection which is
based on the ULID may continue but the ULID should not be used for new
connections.
> 1.6 Placement of the shim
... [snip] ...
> Layering AH and ESP above the multihoming shim means that IPsec can
> be made to be unaware of locator changes the same way that transport
> protocols can be unaware. Thus the IPsec security associations
> remain stable even though the locators are changing.
IMHO, it would be good to mention that IP addresses to be specified in
selector information of security policy should be ULID (if locator agility
is required). I expect that even IKEv1/IKEv2 would also be possible to
run over SHIM6, for instance.
> 1.7 Traffic Engineering
>
> At the time of this writing it is not clear what requirements for
> traffic engineering make sense for the shim6 protocol, since the
> requirements must both result in some useful behavior as well as be
> implementable using a host-to-host locator agility mechanism like
> shim6. What is clear that whatever they are, shim6 will not be able
> to provide identical capabilities to traffic engineering using BGP
> and Provide Independent IP addresses.
It was not clear to me what the above paragraph means.
Could someone elaborate more on this ?
> 2.1 Definitions
>
I think it's better to add definition for "locator agility" which is
one of the key concepts of SHIM6. It might also be helpful to describe
what the "demultiplex" means.
...[snip]...
> 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 current locator
> pairs though.
Is this true ? My understanding is that the two ends (I and R) must
have exactly the same current locator pair for the bi-directional
context. Otherwise, I guess receiver node maybe confused when it
tries to demux the receiving packet. Could someone help me clarify ?
> Forked Instance Identifier (FII) In order to handle context forking,
> a context is identified by a ULID-pair and a
> forked context identifier. The default context
> has a FII of zero.
Is any specific data type defined for FII (eg. unsigned int) ?
> 4. Protocol Overview
>
...[snip]...
> o Some heuristic on A or B (or both) determine that it might make
> sense to make this communication robust against locator failures.
> For instance, this heuristic might be that more than 50 packets
s/heuristic/heuristics/
> 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.
>
...[snip]...
> o In addition to failures detected based on end-to-end observations,
> one endpoint might be know for certain that one or more of its
s/know/known/
...[snip]...
> 4.6 Extension Header Order
>
> Since the shim is placed between the IP endpoint sub-layer and the IP
> routing sub-layer in the host, the shim header MUST be placed 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). 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 effects the location of the shim6 header.
I think this is an interesting issue. Assuming that node A sends packet
to B traversing the tunneling agent C; if the packet from node A happens
to be tunneled by C to B, we have several choices how to apply SHIM6.
I think the consequence would be depending on which entities establish
context. Let me expand it a little bit more.
a) If A and B establish SHIM6 context, a packet received by node B would
look like:
[Outer IP header]
src=C, dst=B
[Inner IP header]
src=L(A), dst=L(B)
[Shim6 Extension header]
...(Payload)...
b) If C and B establish SHIM6 context, a packet received by node B would
look like:
[Outer IP header]
src=L(C), dst=L(B)
[Shim6 Extension header]
[Inner IP header]
src=A, dst=B
...(Payload)...
> In most cases IP-in-IP tunnels are used as a routing technique, thus
> it makes sense to apply them on the locators which means that the
> sender would insert the shim6 header after any IP-in-IP
> encapsulation; this is what occurs naturally when routers apply IP-
> in-IP encapsulation.
I would like to have clarification which case a) or b) does the above
sentence means. IMHO, both a) and b) should be possible. b) is slightly
complex in a sense that SHIM6 packet processing takes place after
forwarding is done (at the router, namely node C in this case) at the
IP layer however it remains logical. Any comments ?
> 7.4 Context confusion
>
...[snip]...
> The requirement is that the old context which used the context tag
> MUST be removed; it can no longer be used to send packets.
Yes, but we should note one thing: Even if a node receives I1 message
with a duplicated context tag proposed by the other end, receiver node
should not delete old context until the context establishment is
successfully done.
...[snip]...
> 7.7 Receiving I1 messages
>
> A host MUST silently discard any received I1 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.
>
> Upon the reception of an I1 message, the host extracts the ULID pair
> and the Forked Instance identifier from the message. If there is no
> ULID-pair option, then the ULID pair is taken from the source and
> destination fields in the IPv6 header. If there is no FII option in
> the message, then the FII value is taken to be zero.
>
> Next the host looks for an existing context which matches the ULID
> pair and the FII. If such a context exists, the host verifies that
> the locator of the Initiator is included in Ls(peer) (This check is
> unnecessary if there is no ULID-pair option in the I1 message). If
> the locators do not fall in the locator sets, then the host MUST
> discard the I1 packet and perform no further processing.
>
> If no state is found (i.e., the state is IDLE), or the locators do
> fall in the sets, then the host looks at the state of the context:
>
> o If the state is IDLE, then the host will form an R1 packet as
> specified below.
>
> o If the state is ESTABLISHED, it means that the Initiator has lost
> the context information for this context and it is trying to
> establish a new one. In this case, the host MUST update the
> existing context and replace CT(peer) with the Initiator Context
> Tag included in the I1 message and then reply with an R2 message,
> including the associated state information. In this case the host
> MUST look for any other (old) context with a matching CT(peer) as
> specified in Section 7.12. This completes the I1 processing, with
> the context state being unchanged.
Same as my previous comment, but I believe the above rule is not good
because it may allow malicious node to send false I1 message (by possibly
spoofing the source IP address) and delete corresponding context.
> 7.8 Receiving R1 messages and sending I2 messages
>
> A host MUST silently discard any received R1 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.
>
> Upon the reception of an R1 message, the host extracts the Initiator
> Nonce and the Locator Pair from the message (the latter from the
> source and destination fields in the IPv6 header). Next the host
> looks for an existing context which matches the Initiator Nonce and
> where the locators are contained in Ls(peer) and Ls(local),
> respectively. If no such context is not found, then the R1 packet is
> silently discarded.
s/no such context is not/no such context is/
> 7.10 Receiving I2 messages
>
> A host MUST silently discard any received I2 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 2, i.e., the length is at least
> 24 octets.
>
> Upon the reception of an I2 message, the host extracts the ULID pair
> and the Forked Instance identifier from the message. If there is no
> ULID-pair option, then the ULID pair is taken from the source and
> destination fields in the IPv6 header. If there is no FII option in
> the message, then the FII value is taken to be zero.
>
> Next the host verifies that the Responder Nonce is a recent one, and
> that the Validator option matches the validator the host would have
> computed for the ULID, locators, responder nonce, and FII.
>
> If a CGA Parameter Data Structure is included in the message, then
> the host MUST verify if the actual PDS contained in the packet
> corresponds to the ULID(peer).
>
> If at least one of the above verification fails, then it silently
> discard the packet and it has completed the I2 processing.
IMHO, it is better to rephrase above paragraph as below:
"If any of the above verification fails, the host MUST silently discard
the packet and complete the I2 processing."
...[snip]...
> 7.12 Match for Context Confusion
>
> When the host receives an I2, I2bis, or R2 it MUST look for a
similar (might be same) comment again, but I believe the verification
discussed here should be applied for I2bis and R2 message. For I2
message, if the CT looks different from the one appeared on I1 message,
the I2 message should be considered invalid.
> possible context confusion i.e. where it would end up with multiple
> contexts using the same CT(peer) for the same peer host. This can
> happen when it has received the above messages since they create a
> new context with a new CT(peer). Same issue applies when CT(peer) is
> updated for an existing context.
>
> The host takes CT(peer) for the newly created or updated context, and
> looks for other contexts which:
>
> o Are in state ESTABLISHED or I2BIS-SENT.
>
> o Have the same CT(peer).
>
> o Where Ls(peer) has at least one locator in common with the newly
> created or updated context.
>
> If such a context is found, then the host checks if the ULID pair or
> the Forked Instance Identifier different than the ones in the newly
> created or updated context:
>
> o If this is true, then the peer is trying to reuse the context tag
> for the creation of a context with different ULID pair or FII,
> which is a signal that the Initiator has lost the other 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
s/MUST not/MUST NOT/
> 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.
>
> o If this is not true, then the local host must be broken, since it
> should have detected the existence of a context for the same ULID
> pair and FII earlier.
>
...[snip]...
> 7.15 Receiving R1bis messages and sending I2bis messages
>
> A host MUST silently discard any received R1bis 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.
>
> Upon the reception of an R1bis message, the host extracts the Packet
> Context Tag and the Locator Pair from the message (the latter from
> the source and destination fields in the IPv6 header). Next the host
> looks for an existing context where the Packet Context Tag matches
> CT(peer) and where the locators match Lp(peer) and Lp(local),
> respectively.
>
> o If no such context is not found, i.e., the state is IDLE, then the
> R1bis packet is silently discarded.
>
> o If the state is I1-SENT, I2-SENT, or I2BIS-SENT, then the R1bis
> packet is silently discarded.
>
> o If the state is ESTABLISHED, then we are in the case where the
> peer has lost the context and the goal is to try to re-establish
> it. For that, the host leaves CT(peer) unchanged in the context
> state, transitions to I2BIS-SENT state, and sends a I2bis packet,
> including in it the Validator, the Packet Context Tag, and the
s/including in it/including it in/
> 8. Handling ICMP Error Messages
...[snip]...
> If the ULP packet had been encapsulated in a shim6 payload extension
> header, then this extension header must be removed. The result needs
> to be that the ULP receives an ICMP error where the contained "packet
> in error" looks as if the shim did not exist.
I understand it is necessary to restore the original packet included in
the ICMP error message. Besides, I wonder if there is any kind of ICMP
error message to which SHIM6 protocol stack should react (e.g. changing
state of corresponding context). For instance, if the node receives
host unreach, should the corresponding host pair context be torn down ?
> 9. Teardown of the ULID-Pair Context
>
> Each host can unilaterally decide when to tear down a ULID-pair
> context. It is RECOMMENDED that hosts not tear down the context when
s/hosts not/hosts do not/
> they know that there is some upper layer protocol that might use the
> context. For example, an implementation might know this is there is
s/this is there is/this if there is/ ?
> an open socket which is connected to the ULID(peer). However, there
> might be cases when the knowledge is not readily available to the
> shim layer, for instance for UDP applications which not connect their
s/which not connect/which do not connect/
> sockets, or any application which retains some higher level state
> across (TCP) connections and UDP packets.
>
> Thus it is RECOMMENDED that implementations minimize premature
> teardown by observing the amount of traffic that is sent and received
> using the context, and only after it appears quiescent, tear down the
> state. A reasonable approach would be to not tear down a context
s/to not/not to/
> until at least 5 minutes have passed since the last message was sent
> or received using the context.
Better to replace "5 minutes" with certain protocol constant
(i.e. MINIMUM_CONTEXT_TIMEOUT).
> Since there is no explicit, coordinated removal of the context state,
> there are potential issues around context tag reuse. One end might
> remove the state, and potentially reuse that context tag for some
> other communication, and the peer might later try to use the old
> context (which it didn't remove). The protocol has mechanisms to
> recover from this, which work whether the state removal was total and
> accidental (e.g., crash and reboot of the host), or just a garbage
> collection of shim state that didn't seem to be used. However, the
> host should try to minimize the reuse of context tags by trying to
> randomly cycle through the 2^47 context tag values. (See Appendix B
> for a summary how the recovery works in the different cases.)
...[snip]...
> 11.1 Sending ULP Payload after a Switch
>
> When sending packets, if there is a ULID-pair context for the ULID
> pair, and the ULID pair is no longer used as the locator pair, then
> the sender needs to transform the packet. Apart from replacing the
> IPv6 source and destination fields with a locator pair, an 8-octet
> header is added so that the receiver can find the context and inverse
> the transformation.
>
> First, the IP address fields are replaced. The IPv6 source address
> field is set to Lp(local) and the destination address field is set to
> Lp(peer). NOTE that this MUST NOT cause any recalculation of the ULP
> checksums, since the ULP checksums are carried end-to-end and the ULP
> pseudo-header contains the ULIDs which are preserved end-to-end.
>
> The sender skips any "routing sub-layer extension headers" that the
> ULP might have included, thus it skips any hop-by-hop extension
> header, any routing header, and any destination options header that
> is followed by a routing header. After any such headers the shim6
> extension header will be added. This might be before a Fragment
> header, a Destination Options header, an ESP or AH header, or a ULP
> header.
>
> The inserted shim6 Payload extension header includes the peer's
> context tag.
What about the next header field in the IPv6 protocol header ? I believe
that SHIM6 should override the next header field of IPv6 protocol header
when locator switch is performed. The new protocol value for SHIM6
(IPPROTO_SHIM6 ?) is to be assigned by IANA. Is my understanding
correct ?
Regards,
Shinta