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

Re: IKEv2 and SCTP support


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 don't claim to understand all
the issues wrt mobility...

>=> 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. 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 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" :-)

>=> 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.

>   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.
-Angelos