Re: IKEv2 and SCTP support

["Angelos D. Keromytis" <angelos@cs.columbia.edu>]

OK, I see your points. What I'd like to hear (from others) is how important
they feel SCTP support in IKEv2 is: does it have to happen *now*, or can it
wait for a future document ?
-Angelos

In message <200307011615.h61GF7of091437@givry.rennes.enst-bretagne.fr>, Francis
 Dupont writes:
> 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 exchang
>e
>   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