Subject: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13)

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Jun 2004 21:24:22 +0300

Does switching from IPv4 to IPv6 or vice versa work?
(Presumably yes. Its hard to see why this would cause
any problems.)
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Mon, 21 Jun 2004 14:51:38 -0400

I would think so too!

Lakshminath

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Jun 2004 10:38:22 +0200

In your previous mail you wrote:

=> you can spread a bit the question: when an implementation supports
many addresses for the same IPsec SA (cf RFC 3554, end of section 2),
can the addresses mix IPv4 and IPv6?

Regards

[email-masked]

PS: IMHO the many simultaneous addresses per IPsec SA is not a good idea
(not necessary and a bit hairy to implement) but when it is supported
it should work with both IP versions at the same time.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Satoshi Inoue <[email-masked]>
Date: Tue, 22 Jun 2004 18:23:34 +0900

On Mon, 21 Jun 2004 21:24:22 +0300

> (Presumably yes. Its hard to see why this would cause

Hmmm... I don't think this would make life easier :-)
How about IPvX capability/reachability checks? Some kind of signaling
is done beforehand?

BTW, are link-locals, scope-zones handled? Implementation dependent?
Well, I think this is not much of a problem as on-link IPsec tunnels
are not realistic though.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 22 Jun 2004 09:59:40 -0700

> can the addresses mix IPv4 and IPv6?
The IKEv2 spec clearly allows this i.e mixing IPv4 and IPv6 traffic selectors
on a single SA.  But these are inner addresses. I thought Jari's question is about
outer addresses ? Jari, can you clarify ?

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Jun 2004 19:13:27 +0200

> can the addresses mix IPv4 and IPv6?

   The IKEv2 spec clearly allows this i.e mixing IPv4 and IPv6 traffic
  selectors on a single SA.  But these are inner addresses. I thought
  Jari's question is about outer addresses ? Jari, can you clarify ?
   
=> I've put the reference to avoid this issue: the question is about
the outer addresses.
   
Regards

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jun 2004 11:58:37 +0300

> => I've put the reference to avoid this issue: the question is about

Yes, it is about the outer addresses.

Originally when I sent the e-mail I was thinking about movement
from an IPv4 address to an IPv6 address. But of course there's
a similar issue with multihoming, as discussed in RFC 3554.

As you Francis and Mohan pointed out, supporting multiple
outer and inner addresses is already in current specifications.
My expectation is that this should also work with MOBIKE, with
both movements and multihoming. I propose that we close this
issue until we find some evidence that we have a problem to
support this :-)

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 18:02:24 +0200

=> but there is a real difference:
 - it is expected that multiple inner addresses will be supported
   by nearly every implementations (the only way to avoid the support
   is to require only single traffic selector pairs but this is like
   to reject not initial exchanges: legal but only for dumb
   implementations).
 - multiple outer addresses for IPsec SAs are very complex to
   implement. BTW, does someone know a complete implementation
   of RFC 3554?

=> I believe that there is a real problem but the problem is partially
outside the scope of MOBIKE. I propose to *not* require the support
of multiple simultaneous outer addresses for IPsec SA without a strong
support from the IPsec WG (as something specific in the 2401bis for
instance).

Thanks

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 24 Jun 2004 09:52:34 -0700

> support from the IPsec WG (as something specific in the 2401bis for
I miss something here. I thought RFC 3554 has the support of the IPsec WG.
All we are saying that this address set can change. And changing addresses
is the core of  MOBIKE.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Thu, 24 Jun 2004 20:30:23 +0200

> support from the IPsec WG (as something specific in the 2401bis for

   I miss something here.

=> the key word is "simultaneous"

   I thought RFC 3554 has the support of the IPsec WG.

=> I am afraid many members of the IPsec WG didn't understand all
consequences of RFC 3554. And if I am wrong (I'd like to be) there
is or will be clarification in the 2401bis...

   All we are saying that this address set can change.
   And changing addresses is the core of MOBIKE.

=> to change is not the problem.

Regards

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Jun 2004 15:08:08 -0400

>is or will be clarification in the 2401bis...

2401bis already mandates support for selector sets that allow a 
single SA to refer to a set of IP addresses and ports, which is one 
of the major requirements for SCTP that was not available under 2401. 
What else do you feel needs to be covered to enable SCTP to work?

Steve

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Jun 2004 00:37:48 +0200

2401bis already mandates support for selector sets that allow a 
   single SA to refer to a set of IP addresses and ports,

=> argh! The term "ports" here disturbs me: we are talking about
the support of multiple simultaneous *outer* addresses (not
traffic selectors aka inner addresses) in the SADB.

   which is one 
   
=> in fact this is not necessary to enable SCTP to work.

Thanks

PS: the exact quote from RFC 3554 is:

   Similarly, SAs may have multiple associated source and destination
   addresses.  Thus an SA is identified by the extended triplet ({set of
   destination addresses}, SPI, Security Protocol).  A lookup in the
   Security Association Database (SADB) using the triplet (Destination
   Address, SPI, Security Protocol), where Destination Address is any of
   the negotiated peer addresses, MUST return the same SA.

The text becomes with a "may" so this is not a requirement. The detail
(introduce by "thus") is about the inbound processing and:
 - is fully compatible with the RFC 2401bis (lookup using the couple
   SPI/protocol) at the exception of "source/destination" terminology
   (RFC 2401bis reserves these to outer addresses and use "local/remote").
 - is easy to implement (just ignore the destination address: if the
   packet comes up to this piece of code it should have a right one :-).
Of course for outbound processing there is a peer address selection issue
and things are not simple at all.
BTW there is a glitch at the beginning of the section 4.1 of the rfc2401bis
I-D 02 and only something about the "tunnel header IP source and
destination address" (and the strange verb "purport" ???) in 4.4.2 (SAD).

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Jun 2004 14:40:58 -0400

>traffic selectors aka inner addresses) in the SADB.

You are right; ports are irrelevant in this context.

Sorry for the confusion.

The SCTP requirement is to map sets of S/D addresses to a single SA 
via the SPD, which we do.  The RFC also calls for mapping traffic 
from a set of destination addresses to a single SA, via the SAD. This 
is something that 2401bis accommodates, in the discussion of inbound 
traffic processing in Section 5.2, step 2, so long as we interpret 
the phrase  "If the packet appears to be IPsec protected and it is 
addressed to this device" as allowing multiple addresses for the 
IPsec device. We will add a note to clarify this.

Steve

---

From: Francis Dupont <[email-masked]>
Date: Sat, 26 Jun 2004 11:25:51 +0200

The SCTP requirement is to map sets of S/D addresses to a single SA 
   via the SPD, which we do.

=> this is about inner addresses aka traffic selectors as the SPD
knows only them, isn't it?

   The RFC also calls for mapping traffic 
   
=> fine, so the inbound case is solved by the introduction of
suitable flexibility. But the outbound case is not and IMHO
to require the support of multiple simultaneous outer addresses
is a bad idea. Of course in an IKE context (as MOBIKE) IPsec SAs
come by pairs and we can't ignore the outbound issue...

Thanks

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Jun 2004 10:52:45 -0400

>knows only them, isn't it?

yes.

>come by pairs and we can't ignore the outbound issue...

Yes, outbound is problematic.  2401/bis is not comprehensive in this 
regard, anyway.  Note that we allude to the problem of finding a 
security gateway that services a set of hosts, but that we don't say 
exactly how to solve the problem, since there is not Wg agreement on 
how to do this.

Steve

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 28 Jun 2004 10:09:40 -0700

> come by pairs and we can't ignore the outbound issue...
RFC 3554 allows you to negotiate a single SA for multiple traffic selectors (See
section 3). As SAs come in pairs, it applies to both outbound and inbound SAs.
So, what is the problem in supporting multiple outer addresses for outbound SA
selection ? Is it an implementation problem ?

-thanks
mohan

---

From: Francis Dupont <[email-masked]>
Date: Mon, 28 Jun 2004 23:41:29 +0200

So, what is the problem in supporting multiple outer addresses for
   outbound SA selection ? Is it an implementation problem ?
   
=> yes, it is an implementation problem: IMHO we should be carefull
and do *not* open this can of worms.

Regards