Re: draft-ietf-shim6-proto-06 : Context confusion

[Sébastien Barré <sbarre@info.ucl.ac.be>]

Hi,

I think that in the previous mail, I had not well in mind the fact that 
the only way for a host to have multiple own context tags is to first 
drop one context, then create a new one with the same context tag, so 
that in any case, there is only one possible context for the context 
tag, with still the possibility of having packets arriving to the newly 
created context, but addressed to the dropped context.

With this in mind, I understand better the interest of having 
non-overlapping locators sets. This way we can work as if the two (or 
more) locator sets were corresponding to different machines.

But in this case the following sentence should probably be adapted a bit 
(section 7.6):
----
The confusion can be detected when I2/I2bis/R2 is received since we
 require that those messages MUST include a sufficiently large set of
 locators in a Locator List option that the peer can determine whether
 or not two contexts have the same host as the peer by comparing if
 there is any common locators in Ls(peer).
----
Now, we could consider the case of a single host with multiple disjoint 
locator sets being seen by its pair as multiple hosts. This is without 
problem except a little subtlety. Here is the adapted example of the 
previous mail :
----
1. host A has two contexts with host B, one with the set of locators 
<A1,B1/B2> and CTx, the other with <A2,B3/B4> and CTy.
2. After some time, host B drops the first context.
3. Now he wants to create another one : <A1,B3/B4> with CTx.
----

When A receives the I2 message from B, it is not able (as should be) to 
detect that it is speaking with the same host, as the locator sets are 
disjoint. As a consequence, the context in A with CT(peer)=CTx will not 
be discarded. We are now in the situation of A possibly sending packets 
to both the discarded context <A1,B1/B2> and the newly created one <A1, 
B3/B4>, using CTx in both cases.
IMHO, this can be detected by B, and should be stated in the draft as 
another case of confusion detection (in fact both confusion and context 
loss detection). For this to be done, section 12.1 could be slightly 
changed, to say that a receiver MUST NOT assume that a packet with the 
shim6 payload extension header and a context tag matching with a context 
is really attached to the context. Rather, to verify this, the source 
locator must be checked against Ls(peer) :
o if the source locator is included in Ls(peer), usual translation is done.
o if the source locator is not included in Ls(peer), then probably this 
packet belongs to an old, dropped context, and an R1bis message MUST be 
sent in this case, in order to recover the previously discarded context 
(in my example <A1,B1/B2>).

I hope this proposal is clearer and more realistic than the one 
described in my previous mail.

Thanks for any comment,

Sébastien.