about draft-ietf-shim6-proto-02.txt

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi,

i send a few comments on the v2 of the protocol draft.

regards, marcelo


1.2  Non-Goals

   This proposal also does not try to provide an IP identifier.

I would rephrase this to something like

   This proposal also does not try to provide a new network
   level identifier namespace separated from current IP address
   namespace.

I mean, we are using the concept of ULID and we are using a designated 
locator as the network level identifier.

1.3  Locators as Upper-layer Identifiers

   For example, the protocol already needs to handle ULIDs that are not
   initially reachable.  Thus the same mechanism can handle ULIDs that
   are permanently unreachable from outside their site.  The issue
   becomes how to make the protocol perform well when the ULID is not
   reachable, for instance, avoiding any timeout and retries in this
   case.

correct me if i am wrong, but i don't think that it is a goal to design 
a protocol that prevents retrials and timeouts when the ULID is a 
routable locator that is circumstantially  unreachable, right? I think 
that what is meant here, is that we want to prevent timeouts and 
retrials when we know a priori that the ulid is not a valid locator 
(like in the case of ulas) right?
If so, i would suggest the following rephrasing:

   The issue
   becomes how to make the protocol perform well when the ULID is known
   a priori to be not reachable (e.g. the ULID is a ULA), for instance,
   avoiding any timeout and retries in this case.

1.6  Placement of the shim

   The MOBIKE WG
   is looking at ways to have IPsec security associations survive even
   though the IP addresses changes, which is a different approach.


I guess that it would be good to add a reference to the actual mobike 
protocol (so that there is a reference when the mobike wg is done)

4.2  Securing shim6

I would add as an additional security technique:

   o  Every control message of the shim6 protocol must carry
      the valid context tag assigned to the particular context.
      This implies that an attacker needs to discover that
      context tag before being able to spoof any shim6 control
      message. Such discovery probably requires to be along the
      path in order to be sniff the context tag value. The result
      is that through this technique, the shim6 protocol is
      protected against off path attackers.

4.3  Overview of Shim Control Messages

   There is a No Context error message defined, when a control or
   payload packet arrives and there is no matching context state at the
   receiver.  When such a message is received, it will result in the
   destruction of the shim context and a re-establishment.


I guess that this is under discussion, but just as a remainder...
I guess that the current idea would be not to discard but to try to 
recover the lost context, right?
( i mean reestablishment without previous discard)

5.9  Update Request Message Format

   The following options are allowed in the message:
   Locator List:  The list of the senders (new) locators.  The locators
                  might be unchanged and only the preferences have
                  changed.
   Locator Preferences: Optionally sent when the locators don't all have
                  equal preference.
   CGA Signature: Included when the some of the locators in the list use
                  CGA (and not HBA) for validation.

In addition, i think we need to allow this message to carry the CGA 
Parameter Data structure Option, in order to support the case when the 
I2/R2 packets didn't carry the locator list, and didn't carry the CGA 
parameter data structure... (either this or we must mandate that the 
CGA parameter data structure is carried both in the I2 and R2 packets)

I think that the idea would be to allow the update request message to 
carry the CGA parameter data structure in it, so that this is aligned 
with the comment made in the R2 packet description saying "Locator 
List:  _Optionally_ sent when the responder immediately wants to tell 
the initiator its list of locators." (emphasis mine)

6.1  Conceptual Data Structures

I don't know if timers involved should be included in here, but in case 
they should, i guess that at least the time used to tear down the 
context should be described here.
An option for this would be the time elapsed since the last data or 
control packet associated to the context was exchanged.
The timers involved in context establishment may also need to be 
included here.
In addition, i guess that the multiple timers involved in path 
exploration and failure detection would be needed, but probably those 
are better to be described in the failure detection protocol document.

7.2  Concurrent context establishment

   If a host has received an I1 and sent an R1, then a ULP can trigger
   it to send an I1 message itself, since it doesn't retain any state
   when receiving the I1 message.  Thus while one end is sending an I1
   the other is sending an I2.

I am not sure in this case why it is useful that the initiator replies 
to the I1 sent by the responder with an R2... as i see it, the previous 
I2 message should get to the responder, making him to issue a R2 back. 
The R2 sent by the initiator will have no effect in the responder as i 
understand it... wouldn't make sense to remove this R2 then? Perhaps it 
would be better to reply with an I2 instead of an R2?
I mean, that the initiator replies to the I1 of the responder by 
repeating the I2 instead of sending a new R2... this would keep the 
roles simpler imho, since the initiator would always send I messages 
and the responder R messages...

7.4  Context confusion

I think that the context confusion scenarios may be even more complex 
than the cases described.

For instance consider the case where A and B were communicating and 
established a context with A1 and B1 as ulids. Locator pairs for this 
context are (A1,A2) and (B1,B2) respectivelly. B has allocated context 
C1 for this context.
Now B looses context state.
Later on, B sets up a new context with A but instead of using B1 as 
ulid, it uses B3 (which was not the previous ulid nor it was included 
in the locator set for the previous context)
So, far, A cannot detect that B is the same peer with A has another 
context established with.
Later on, B decides to add B2 as a valid locator for the new context. 
At this point, A realizes that B is the same host than earlier and it 
has a conflict since the tuple (local locator, remote locator, context 
tag) does not uniquely identifies a single context anymore.

I mean, there is an even delayed moment where A can detect the context 
confusion and that is when B decides to add a previous locator in the 
locator set of the new context.
I don't know if this brings additional difficulties... i guess that the 
possible solutions for this still apply, but the moment of discarding 
the old context may not only be at the establishment phase but also 
later on

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.

Or that a failure has just affected the path between the ulids... right?
would it make sense to try to recover here? i.e. using alternative 
locator pairs for exchanging the initial exchange packets and carrying 
different ULID pair as an option?





Editorial

Abstract

   The hosts in a site which has multiple
   provider allocated IPv6 address prefixes, will use the shim6 protocol
   specified in this document to setup state with peer hosts, so that
   the state can later be used to failover to a different locator pair,
   should the original one stop working.

s/stop/stops

(the same comment in the Introduction)

5.2  Payload Message Format

   The payload message is used to carry ULP packets where the receiver
   must replace the content of the source and or destination fields in

s/and or/and/or

5.9  Update Request Message Format

   Thus there is no
   mechanisms to just send deltas to the locator list.

s/mechanisms/mechanism

5.15.3  Locator Preferences Option Format

   When the Element length equals one, then the element consists of only
   a flags field.

the "1 octet" is missing
I think it should read:

   When the Element length equals one, then the element consists of only
   a 1 octet flags field.

5.15.5  CGA Signature Option Format

   When CGA is used for validation of one or more of the locators in the
   PDS,

The locators in the Locator List option rather than in the PDS

so it should read:

5.15.5  CGA Signature Option Format

   When CGA is used for validation of one or more of the locators in the
   Locator List option,

7.6  Receiving I1 messages

   If the host looks up a context for the ULID pair and the peer's (not
   its) context tag.

I guess that the initial if should be removed

10.  Teardown of the Host Pair Context

   However, there
   might be cases when the knowledge is not readily available to the
   shim layer, for instance for UDP applications which not not connect

rm not