Re: Comments on draft-nordmark-multi6dt-shim-00.txt

[Erik Nordmark <erik.nordmark@sun.com>]

Thanks for the comments.

Mohan Parthasarathy wrote:
> This draft was pretty easy to read. Here are some questions/comments
> on the draft.
>
> 1) In section 5,
>
> The context state in this approach is maintained per remote ULID i.e.
>  approximately per peer host, and not at any finer granularity.  It 
> might make sense to merge the context state for multiple ULIDs 
> assigned to the same peer host, but this is for further study.
>
> What does "maintained" above mean ? Section 9.3 says that transmit
> side locates the context based on (ULID (local, remote) and receive
> side based on tags etc. A bit of clarification would help here.

What it should say is that it's per host/ULID, and not per TCP
connection. I'll make that more explicit.

> Also, i don't know what merging means above ? I guess you still need
> to maintain explicit state on both ends so that two connections
> between same hosts using different ULID pairs (A1, B1), (A1, B2) but
> same locators will need to be demuxed differently ?

Yes, but if A discovers that ULID B1 and B2 points to the same host
(by both contexts having the same verified locator sets <B1, B2>), then
A could perform the reachability probing more efficiently; it wouldn't
have to probe B1 and B2 independently for each context.

> 2) Section 8 protocol walkthrough does not talk about some details
> e.g. how HBA is used. In 8.2, it talks about locator change. But a
> little bit more detail would help here. I assume that HBA state is
> established initially and verified only when the locator set is
> different from the ULID. Is that right ? Again this is not clearly
> specified anywhere (i have not read all thedocuments closely, so i
> could be missing something).

And intentionally so. We wrote the draft without assuming that the
collection of drafts would fit together, hence this draft doesn't assume
 that redirection attacks are prevented using HBA.

Once we have a protocol draft these things will become more clear.

> 3) In Section 9, will the following approach also work :
>
> Never use the same set of locators across two different connections
> between the same hosts. I know it is not the best option, but for
> discussion it is okay i guess.

The DT discussed that, and the problem is that you can't tell a priori
whether two peers share an IP stack. For instance, if A connects to
www.foo.com with AAAA=B1 and www.bar.com with AAAA=B2 it can't tell
whether B1 or B2 are assigned to the same IP stack or not until it
communicates with B1 and B2 and retrieves there complete locator sets.
(And even this might not suffice, since the peer might want to preserve
the illusion of being two different hosts by returning B3 as an
alternative locator for B1 and B4 as an alternate for B2.)


> I can understand how the methods 9.1.1 and 9.1.2 helps the receiver
> map from locators to the identifier. But this is not sufficient to
> just enough to map locators to identifier. You also need someway to
> find out whether the locator pair has changed and if so validate it.
> You need to do two things on the receiver :
>
> 1) Map from the locator to to the right upper layer identifier. 2)
> Make sure that the locators are part of the same HBA set (or some
> such mechanism to prevent redirect attacks).
>
> How does these two steps happen for 9.1.1 and 9.1.2 ? As identifier
> is known a priori, i can see how (1) happens. How about (2) ? Is
> there still some state maintained at M6 layer ? How is that state
> looked up ?  Some clarification would help.

You'd still have multi6 state at the receiver; without any state the IP 
address fields would not be modified by the M6 layer.
When this state is established, and when the locator set in the state is 
modified by the peer, would the locator set be verified. (You need the 
state to be able to rewrite the IP source address field, even if the 
destination address field rewrite is implicit from the destination 
locator in the packet.)

> 4) In section 9.2.1 (Flow label),
>
> The limitation imposed by this approach is that all the potential
> source and destination addresses have to be known beforehand by the
> receiver in order to be recognized.  This means that before sending
> packets with a new address, the sender has to inform the receiver
> about the new address.
>
> I thought this is needed irrespective of which scheme we use ? Why is
> this specific to the method ?

The possible goal/requirement would be generic.
The test is trying (and failing) to point that it might be beneficial to 
 accept packets from unknown source locators (the rules for packet 
injection can probably be more relaxed than for where packets are sent, 
for instance if the context tag matches). Requiring a match on <source 
locator, destination locator, flow label> would not make this possible 
instead the locator change signaling would need to be acknowledged 
before the peer can start using a different source locator.

> 5) In section 9.2.2, context tag required only when the locator is
> different from identifier. M6 layer is bypassed when there is no
> extension header. Is that right ?

Yes.

   Erik