Re: I-D ACTION:draft-ietf-ipsec-sctp-06.txt

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

=> Please don't send an HTML copy of the body...
   
   The draft (in the end of Section 2, below) appears to propose a new
   requirement that remote access tunnel mode IPsec users MUST use an inner IP
   address equivalent to their outer address (or else it reclassifies such
   users as "security gateways").  This seems to directly contradict all the
   work with DHCP over IKE and the entire Configuration Payload discussion, all
   of which is based on assigning an inner tunnel address which can be a part
   of a VPN address domain (i.e., different from the outer address).
   
   Am I missing something (besides my second cup of coffee)?
   
=> I believe this draft is about IKEv1 and IKEv2 can be different...
I can say this issue stresses the need of an address management
(so the fact a node can use several own addresses is taken into account
and the "same address" becomes "address which belongs to the same node",
the issue is solved at the price to have to implement the belonging (?)
check).
   
   >From Section 2:
      When operating in tunnel mode, the question of what to use as the
      tunnel destination address (for the "outer" header) arises.  We
      distinguish three cases: where the end hosts are also the tunnel
      endpoints; where neither host is a tunnel endpoint (the tunnel
      endpoints are security gateways); and where only one of the hosts is
      a tunnel endpoint (the usual case for the "road warrior" talking to
      a security gateway).  In the first case, the outer addresses MUST be
      the same as the inner addresses of the tunnel.  In the second case
      (security gateways) there is no special processing; address
      selection proceeds as it would for two distinct sets of end hosts.
      In the third case, the "road warrior" uses the security gateway's
      address as the tunnel destination address, and MUST use the same
      source address as that of the inner packet.  Symmetrically, the
      security gateway uses its own address as the source address of the
      tunnel, and MUST use the the same destination address in the outer
      header as that of the inner packet.  An implementation will probably
      structure the code so that if, during SA setup, the inner and outer
      address of either side is the same, rather than explicitly store the
      corresponding address of the tunnel, it sets a flag that marks the SA
      to use the same address in the tunnel header as in the inner header.
   
=> I have to confess that I don't understand why the draft requires the
same address when all the text before this paragraph shows it should only
require that the inner address and the outer address (aka the peer address)
belongs to the same node, i.e., is member of the address set!
 Perhaps this is a consequence of the usual confusion between inner and
outer addresses when we talk about SPD and SADB selectors... But the draft
is clear about this issue, SPD selectors are trafic selectors and match
the inner address. There is no SADB selector involved: the text is about
the incoming processing and uses explicitely the outer address (the right
term, "peer address", is in the text) for the SA lookup.
 The only reason (which is not in the draft) I can find is to make things
simpler, i.e., disallow flexibility between inner and outer addresses.
Of course, I share your concern, i.e., this doesn't work when some addresses
have not the same status than others. I am waiting the answer from the
authors!

Thanks

Francis.Dupont@enst-bretagne.fr

PS: my address management proposal convers the multi-homing case so works
well with SCTP. For instance, it provides a very easy way to negociate
the set of addresses in all "phases".
PPS: BTW the draft should reference the PKIX document, aka RFC 3280,
in the certificate discussion (3-2-a).