Subject: Re: IKEv2 and SCTP support

From: Francis Dupont <[email-masked]>
Date: Tue, 01 Jul 2003 10:40:59 +0200

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

[email-masked]

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 01 Jul 2003 09:40:38 -0400

In message <[email-masked]>, Francis
>with the mobility stuff (in fact, SCTP/multi-homing and mobility share

Well, SCTP without mobility is simple to fix. I don't claim to understand all
the issues wrt mobility...

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

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

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

>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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 01 Jul 2003 18:15:07 +0200

In message <[email-masked]>,

   >with the mobility stuff (in fact, SCTP/multi-homing and mobility share
   
   Well, SCTP without mobility is simple to fix.

=> I disagree: IKEv2 and the SCTP document changed the IKEv1 ID mess in
very different ways.
   
   >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.

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

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

   >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

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 01 Jul 2003 12:14:38 -0400

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 <[email-masked]>, Francis