Re: IKEv2 and SCTP support

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

 In your previous mail you wrote:

   In message <200307010840.h618exof089503@givry.rennes.enst-bretagne.fr>,
   Francis Dupont writes:

   >=> 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)?
   
   Well, SCTP without mobility is simple to fix.

=> I disagree: IKEv2 and the SCTP document changed the IKEv1 ID mess in
very different ways.
   
   >=> there is a third way: add an explicit management of peer address set
   >as I suggested in my draft.
   
   The drawback is that there is an extra message etc.

=> extra message? No, there is no extra message for the SCTP part.

   Also, as we discuss in RFC
   3554, it is unlikely that you will be getting a new address extremely
   frequently (e.g., every minute), so you might as well do a full IKE exchange
   when you do.
   
=> this is an argument against the inclusion of a peer address update
payload for SCTP in the current IKEv2 draft. It seems we already agree
to postpone this. My proposal for SCTP is more about a peer address set
management which comes before a SA update mechanism.

   >=> this is another overloading of the ID payload. IMHO we can do better,
   >so the question is postpone or delay?
   
   Except that we have already taken this approach for IKEv1, and the text
   can be copied directly, so the third option is "integrate" :-)

=> but this implies to go backward on everything about phase 1 IDs
in IKEv2. I don't believe we can reach a consensus about this: I am
afraid that the common answer will be "please wait".
   
   >=> 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.
   
   That's incorrect. ID_LIST can be sent in "phase 1" as well.
   
=> this is not what it is written in draft-ietf-ipsec-sctp-06.txt.
The ID_LIST is defined for phase 2 and the phase 1 text begins
by "Specify multiple Phase 1 IDs". But the problem is not there.

   >   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...
   
   PKIX certificates already support this type of encoding, and
   matching against it is trivial. Again, the changes I recommend are
   purely textual, as opposed to adding a new message or exchange.

=> my concern is not that this is difficult to implement (of course
it is not) but this is based on a specific semantics of phase 1 IDs:

   ... Currently, IKE can directly accommodate the simple case of two
   machines talking to each other, by using Phase 1 IDs corresponding
   to their IP addresses, and encoding those same addresses in the
   SubjAltName of the certificates used to authenticate the Phase 1
   exchange.

when IKEv2 just does the opposite:

   The Identification Payloads, denoted IDi and IDr in this memo, allow
   peers to assert an identity to one another. This identity may be used
   for policy lookup, but does not necessarily have to match anything in
   the CERT payload; both fields may be used by an implementation to
   perform access control decisions.

IMHO we had enough problems with the overloading of IKEv1 IDs: please
don't add anything on the shoulders of IKEv2 IDs! Don't forget some
of us proposed to remove the ID payload... (ultimate cleanup :-)

Thanks

Francis.Dupont@enst-bretagne.fr