Re: comments on draft-ietf-shim6-proto-03

[Shinta Sugimoto <shinta@sfc.wide.ad.jp>]

Hello Erik,

Thank you for your feedback.  Please find my comments inline:

On Tue, 14 Feb 2006 16:36:02 -0800
Erik Nordmark <erik.nordmark@sun.com> wrote:

> Shinta Sugimoto wrote:
> > 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.
> 
> Thanks for your comments and sorry for the tardy response.
> I've used your comments as an indication where we can make the document 
> more clear, and I've applied your typo fixes.
> 
> >>    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 ?
> 
> What it means (and I'll clarify the document) is that we don't require 
> some extra shim6 handshake before TCP/UDP/etc packets can flow. Instead 
> normal TCP/UDP/whatever packets can flow and later and in parallel the 
> shim6 context can be setup.

Ok, I see.  I agree that it (deferred setup) is important and should be
one of the goals.

> > I am not sure if there is semantic difference between "load balancing"
> > and "load spreading", but the former sounds more familiar to me.
> 
> I'll switch back to "balancing" since that is more common.
> 
> One can make a distinction between "balance" as a way to enforce a 
> particular split (e.g., a 50/50 balance), and the techniques in shim6 to 
> have different connections (from the same or different hosts) pick at 
> random between multiple destination addresses doesn't ensure "balance" - 
> a single connection might represent the bulk of the traffic. Hence I 
> used "spreading" for this for loose concept.

Ok.

> 
> > 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.
> 
> The approach doesn't prevent the receiver of multicast to change its 
> locators, since the receiver is not explicitly identified; the 
> destination address is a multicast address and not the unicast locator 
> of the receiver.

You are right.  I think I misunderstood the issue.  In IP multicast,
locator change of the receiver is invisible to the sender.  Current
texts in Section 1.4 seem just fine.

> > 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.
> 
> I see the text is missing the introductory material which explains that 
> the "locator role" of the IPv6 address can be renumbered away; it is the 
> "ULID role" which raises the issue.

Exactly.

> I'll start the section as:
> <t>As stated above, this approach does not try to make communication
> survive renumbering in the general case.</t>
> 
> <t>When a host is renumbered, the effect is that one or more locators become
> invalid, and zero or more locators are added to the host's network 
> interface.
> This means that the set of locators that is used in the shim will change,
> which the shim can handle as long as not all the original locators become
> invalid at the same time.</t>
> 
> <t>But IP addresses are also used as ULID, and making the communication
> survive locators becoming invalid can potentially cause some confusion 
> at the
> upper layers. <old text>

Ok, I think it's better to add above texts.

> > 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.
> 
> I'll add something.

Ok.

> >> 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 ?
> 
> Let me know if this is more clear:
> 
> Inherent in a scalable multihoming mechanism that separates locators 
> from identifiers 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 is quite different than the common case of IPv4 multihoming where 
> the site has a single IP address prefix, since in that case the peer 
> performs no destination address selection.
> 
> Thus in "single prefix multihoming" the site, and in many cases its 
> upstream ISPs, can use BGP to exert some control of the ingress used to 
> reach the site. This capability can't easily be recreated in "multiple 
> prefix multihoming" such as shim6.

I am not sure if I understand the above texts correctly, but my
interpretation of above texts is that the host centric approach
(or the concept of id-locator split) of SHIM6 in which a host should
deal with multiple locators at a time has implications on source &
destination address selection to be done by the end nodes.
In contrasts, under single prefix multihoming environment, there is
no such requirements for the end nodes but routers inside the network
are required to somehow manage routing information so that the IP
packets destined to the node which has IP address derived from the
multihomed prefix.  But,, I wonder how this relates to Traffic
Engineering.  I should admit that I don't have deep insight into
Traffic Engineering, though.

> 
> > ...[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 ?
> 
> They can be different. The locator *sets* known by the two ends will be 
> the same, but each end can independently decide to switch over to use a 
> different locator pair for the packets it is sending.
> 
> The receiver uses the set of locator pairs for the demux in combination 
> with the context tag. For the data packets the 47-bit context tag is all 
> the receiver needs to check for demuxing.

I see.

> 
> >>    Forked Instance Identifier (FII) In order to handle contxt 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) ?
> 
> Presumably a future ULP-to-SHIM6 API document will define the exact data 
> type. Presumably one doesn't have to support a lot of forked contexts, 
> thus a 32-bit FII would certainly be sufficient.

Ok.

> 
> >>    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/
> 
> Singular form is without the 's' AFAIK.

I am not a native English speaker but my dictionary says that "heuristic"
is adjective and "heuristics" is noun (uncountable).

> 
> >>    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/
> 
> s/be// is even better

Ok.

> 
> > 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)...
> 
> Yes, those options do exist.
> b) is basically applying a shim to the tunnel itself, and perhaps there 
> will be some use for this in some cases.

I agree.

> >>    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 ?
> 
> For Mobile IPv6 tunnels (which was on my mind when writing the above) it 
> makes sense to apply the shim above the tunneling layer.
> So the text does refer to case a), even if that's hard to see from 
> reading it.

Ok.

> 
> I'll use your text to more clearly state the options.
> 
> 
> >> 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.
> 
> Yes, I think that text exists in the detailed descriptions in 7.7 etc, 
> but it makes sense to add it in 7.4 as well.

Ok.

> >>
> >>    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.
> 
> Correct. I think Marcelo had found this, but not send it to the mailing 
> list. Basically we shouldn't update CT(peer) until after a 3-way handshake.

I agree.

> >>    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."
> 
> Yes, that's better.
> 
> >> 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.
> 
> I don't understand the case. There is no state created on the reception 
> of the I1. But the initiator can't change the CT because it is included 
> in the verifier option computation. So what case do you think is 
> problematic?

Sorry, I think I misunderstood.  After I reread the descriptions about
context confusion, I understood that the descriptions in Section 7.12
are correct.  In other words, verification for context confusion should
be performed whenever CT is proposed by the peer (after 3-way handshake).
Understood.

> 
> 
> > 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 ?
> 
> The draft-ietf-shim6-failure-detection-03.txt document treats those as 
> hints. In any case, they are not used to fail the shim6 context/ULID but 
> a hint that the destination locator is unreachable.

I see.  With regard to the reachability failure which happens to be
indicated by the ICMPv6 error message, they should be an input to the
REAP mechanism as a hint.  That seems reasonable.

> > Better to replace "5 minutes" with certain protocol constant
> > (i.e. MINIMUM_CONTEXT_TIMEOUT).
> 
> I don't know if this needs to be a constant; different implementations 
> can pick different values based on their judgement of how long their 
> applications might use a context when there is no connected socket. For 
> instance, an implementation that uses different APIs than the socket API 
> might be able to know all the references applications retain to remote 
> IP addresses, in which case it can tear things down immediately when the 
> last reference is gone.
> So I think 5 minutes is an example.

Ok, I agree that duration of tear down timeout depends on use cases.
As the text says "A reasonable approach would be to ...", so the "5 minutes"
should be regarded as an example.

> >> 11.1  Sending ULP Payload after a Switch
> 
> > 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 ?
> 
> You're correct. I've added that description.

Ok.


Regards,
Shinta