[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKEv2 and SCTP support



 In your previous mail you wrote:

   IKEv2 does not seem to currently support SCTP along the lines of the 
   soon-to-be-issued RFC 3554 (which describes how to do SCTP support
   in IKEv1).
   
=> I agree but is it important to fix this now or can we postpone this
with the mobility stuff (in fact, SCTP/multi-homing and mobility share
a lot of things)?

   Briefly, there are two issues:
   
   a) The traffic selectors must allow for a list of addresses to be associated
   with each endpoint. This is in fact supported by IKEv2.
   
=> yes, this is already handled by the IKEv2 "TS_LIST" feature.

   b) The IKE and IPsec SAs must be linked to all of the peer's remote
   addresses.  This means that IKEv2 cannot just use the peer's IP
   address, but has to either extract all the addresses from the Traffic
   Selector or be told explicitly via the ID payload.

=> there is a third way: add an explicit management of peer address set
as I suggested in my draft.

   IKEv1/SCTP used the latter approach, specifying the ID_LIST
   payload for including a list of IP addresses associated with the peer.

=> this is another overloading of the ID payload. IMHO we can do better,
so the question is postpone or delay?

   I recommend that said payload be included in the IKEv2 draft, and
   the relevant language be copied from RFC 3554.
   
=> argh! I am afraid that you missed a small detail: the ID_LIST is
specified for the phase 2 so if you'd like to change the ID payload
of IKEv2 which is *only* for phase 1 it is not so simple.

   Furthermore, per soon-to-be-issued RFC 3554, the receiver must
   verify that the peer actually owns the relevant addresses in the TS
   payload. This typically means that these addresses must be
   contained in the certificate contained in the CERT payload, or some
   policy/configuration mechanism be consulted.

=> this too shows that the ID payload way is not the right one because
we remove this kind of constraints in the standard case. Of course,
something should be done, and it will be nice to support changes
in the peer address set...

Thanks

Francis.Dupont@enst-bretagne.fr