Subject: [Mobike] TS updates in MOBIKE

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 1 Nov 2007 18:46:26 -0700

Hi,
RFC4555 only allows updates to tunnel endpoint addresses and not
selectors, etc.  Does anyone know why TS updates are not permitted?  If
MOBIKE allowed what an SA rekey would allow, what is the problem?  

Thanks,
Vidya
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Nov 2007 07:25:41 +0200

Presumably because MOBIKE is a mobility and multihoming
facility for IPsec clients and gateways, i.e., you can change
the outer IP addresses. Its not a general SA renegotiation
facility.

Yes, it could be done, but I'm not sure that's really within
the scope of the feature. Unless we are talking about
extension to deal with transport mode, which has been
something at least a few people were interested in.

Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 2 Nov 2007 10:43:03 -0700

Hi Jari, 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2007 10:26 PM
> To: Narayanan, Vidya
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Mobike] TS updates in MOBIKE
> 
> the outer IP addresses. Its not a general SA renegotiation facility.
> 

Yes, I understand that that is the purpose of MOBIKE.  But, I don't see
a good reason to prevent other updates from happening as part of that
same exchange.  For e.g., let's say that when my address changes, I want
to update the SA (or rekey) to start encrypting some additional traffic
(fitting different selector criteria) using the same SA - the initiator
now has to do separate MOBIKE and rekeying exchanges, which is not
really efficient. 

> something at least a few people were interested in.

I think the above point of updating the SAs applies equally to transport
and tunnel mode, but, extending MOBIKE for transport mode is
independently useful in my view. 

Regards,
Vidya

> > selectors, etc.  Does anyone know why TS updates are not 
> permitted?  
> > If MOBIKE allowed what an SA rekey would allow, what is the problem?
> >
> > Thanks,
> > Vidya

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 2 Nov 2007 15:44:14 +0200

Narayanan, Vidya writes:
> selectors, etc.

Yes, as that was outside the charter of the mobike.

> Does anyone know why TS updates are not permitted?

It is already done by the IKEv2 protocol, with fast and efficient
exchange called CREATE_CHILD_SA... I.e. if you need it simply, create
new SA with new traffic selectors, and delete the old one.

> If MOBIKE allowed what an SA rekey would allow, what is the problem?

All traffic going through the SA would usually stop, as it would not
know it needs to change the IP addresses, thus it would still be using
the original addresses, and it wouldn't fit to the new SA.

I.e. as the idea is that the for example TCP streams running inside
the IPsec SA using mobike, keeps exactly same IP addresses all the
time, so the TCP do not notice the movement at all. When outer
addresses change, the inner addresses stay same, and TCP will only see
those inner addresses it will stay happy. If those inner addresses
would change then TCP streams running on old addresses would be broken
and connections would be lost unless the TCP stack was also modified
to update the addresses.

So in mobike case there is no need to update the inner addresses, and
if someone makes some real world scenario where such thing is needed
CREATE_CHILD_SA will solve the problem for him...
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 4 Nov 2007 18:17:49 -0800

Chinh, Steve, Tero,
Thanks for all the responses.  I'm just taking Chinh's email here to
make a few observations. 

> From: Chinh Nguyen [mailto:[email-masked]] 
> Sent: Friday, November 02, 2007 12:34 PM
> To: Narayanan, Vidya
> Cc: Jari Arkko; [email-masked]; [email-masked]
> Subject: Re: [IPsec] RE: [Mobike] TS updates in MOBIKE
> 
> Efficiency is overrated.
> 

Well, not that overrated over licensed wireless spectrum :) 

> But all joking aside, the UPDATE_SA notify payload is part of 
> an informational exchange. Informationals do not contain the 
> necessary payloads to "update an SA" such as TS, KE, and even 
> SA payloads.
> 

Yes, that is true.  I guess what I was really asking was what you were
getting at immediately below. 

> The alternative is to allow the UPDATE_SA notify payload to 
> be part of a CREATE_CHILD_SA message. If so, it must be 
> further specified that there are now 2 ways to UPDATE_SA: a 
> regular end-point update via an informational, and a 
> end-point + TS + [etc.] update via a create child sa.
> 

Yes, but, I'm not sure if that's a big deal.  It is, after all, a notify
payload and the processing of the payload itself doesn't change.  So, in
essence, we would just be lifting the mandate to only allow it to be
carried in an informational exchange. 

> Since this is a reasonably major change to the MOBIKE spec, 
> which is already an RFC, you may need a compelling use-case scenario.
> 

The use case that I presently have in mind is the following.  IPsec is
used in some cases to protect Mobile IPv6 (MIP6) signaling.  Some
systems differentiate between trusted accesses and untrusted accesses
and while IPsec is always used for MIP6 signaling protection in both
cases, additional data protection using IPsec may be needed over
untrusted access networks (between the same endpoints).  When a mobile
is moving from a trusted to untrusted access, its IP address changes,
but, it also, at the same time, needs to update its SA to start
protecting all traffic.  At the moment, the mobile, just to handle this
handoff case, needs to do a MIP6 signaling exchange, a MOBIKE exchange
and a CREATE_CHILD_SA exchange.  The first two are unavoidable and can
happen in parallel, while the third one has to occur after the MOBIKE
exchange completes.  This is a latency hit in the critical path that can
be avoided if the UPDATE_SA notify payload can be part of the
CREATE_CHILD_SA exchange. 

> A saving of 2 additional packets (for the extra rekey to 
> change the TS) may not be sufficient reason to blur the 
> current functional boundaries.
> 

Well, depending on the environment we are talking about, byte savings
and particularly latency becomes important.  Does the removal (or
relaxing) of these tight functional boundaries really cause any issue?
If not, I think allowing this can really help some use cases like the
above. 

Regards,
Vidya

> Chinh
> http://www.certicom.com
> Narayanan, Vidya wrote:
> facility for 
> >> IPsec clients and gateways, i.e., you can change the outer IP 
> >> addresses. Its not a general SA renegotiation facility.
> >>
> > 
> > Yes, I understand that that is the purpose of MOBIKE.  But, I don't 
> > see a good reason to prevent other updates from happening 
> as part of 
> > that same exchange.  For e.g., let's say that when my 
> address changes, 
> > I want to update the SA (or rekey) to start encrypting some 
> additional 
> > traffic (fitting different selector criteria) using the 
> same SA - the 
> > initiator now has to do separate MOBIKE and rekeying 
> exchanges, which 
> > is not really efficient.
> > 
> >> Yes, it could be done, but I'm not sure that's really within the 
> >> scope of the feature. Unless we are talking about 
> extension to deal 
> >> with transport mode, which has been something at least a 
> few people 
> >> were interested in.
> >>
> > 
> > I think the above point of updating the SAs applies equally to 
> > transport and tunnel mode, but, extending MOBIKE for 
> transport mode is 
> > IPsec mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ipsec
>

---

From: <[email-masked]>
Date: Mon, 5 Nov 2007 09:22:56 +0200

Vidya Narayanan wrote:

> The use case that I presently have in mind is the following.  IPsec
> is used in some cases to protect Mobile IPv6 (MIP6) signaling.  Some
> systems differentiate between trusted accesses and untrusted
> accesses and while IPsec is always used for MIP6 signaling
> protection in both cases, additional data protection using IPsec may
> be needed over untrusted access networks (between the same
> endpoints).  When a mobile is moving from a trusted to untrusted
> access, its IP address changes, but, it also, at the same time,
> needs to update its SA to start protecting all traffic.  At the
> moment, the mobile, just to handle this handoff case, needs to do a
> MIP6 signaling exchange, a MOBIKE exchange and a CREATE_CHILD_SA
> exchange.  The first two are unavoidable and can happen in parallel,
> while the third one has to occur after the MOBIKE exchange
> completes.  This is a latency hit in the critical path that can be
> avoided if the UPDATE_SA notify payload can be part of the

If the IKE implementation supports window size larger than 1,
can't the Informational exchange (with UPDATE_SA notify payload)
and CREATE_CHILD_SA exchange occur in parallel, too?

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 5 Nov 2007 16:12:06 +0200

> CREATE_CHILD_SA exchange. 

Why it cannot happen in paralleal with UPDATE_SA exchange? IKEv2
already has mechanisms defined for using bigger window for IKEv2, so
you just need to enable using of window size of 2 or larger in the
IKEv2, to be able to do UPDATE_SA and CREATE_CHILD_SA in paralleal,
thus now latency hit at all. Or is there some other reason they cannot
be done in paralleal?

> and particularly latency becomes important.

There is no latency problem, so the only problem is the extra 80 bytes
sent and received.

> Does the removal (or relaxing) of these tight functional boundaries
> really cause any issue? If not, I think allowing this can really
> help some use cases like the above.

As there is already efficient ways to do that in the IKEv2, I do not
see any reason to add another different way to get the same results
only to save 160 bytes every time transition from trusted to untrusted
network happens (most likely at maximum few times per day...)
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Nov 2007 17:31:33 -0800

> A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it 
> arrives from an "unknown" endpoint (SPIs + src/dst addresses 
> are used to track IKEv2 exchanges). In such case, the 
> CREATE_CHILD_SA will fail if a. the CREATE_CHILD_SA arrives 
> before the UPDATE_SA exchange or b. the CREATE_CHILD_SA 
> arrives while the peer is doing a route check to complete the 
> UPDATE_SA exchange.
> 

Yes, this is what I was getting at.  

> However, this can be mitigated by having the IKEv2 peer use 
> only the SPIs to track IKEv2 exchanges and ignore src/dst addresses.
> 

This gives the impression that the IP address to which the IKE_SA is
tied is not important.  That is the address that is going to serve as
the tunnel endpoint for tunnel mode SAs and hence, has some consequence.
I would think that typical implementations reject CREATE_CHILD_SA
requests for rekeying an SA, sent from a different IP address than to
which the IKE_SA is currently tied - is that not true?  RFC4306 is not
clear about this. 

Thanks,
Vidya

---

From: <[email-masked]>
Date: Wed, 7 Nov 2007 11:47:07 +0200

Vidya Narayanan wrote:

> tied is not important.  That is the address that is going to serve
> as the tunnel endpoint for tunnel mode SAs and hence, has some
> consequence.  I would think that typical implementations reject
> CREATE_CHILD_SA requests for rekeying an SA, sent from a different
> IP address than to which the IKE_SA is currently tied - is that not
> true?  RFC4306 is not clear about this.

We faced this question when designing MOBIKE, and resolved
it as follows (RFC 4555, Section 3.3):

   When an IPsec SA is created, the tunnel header IP addresses (and
   port, if doing UDP encapsulation) are taken from the IKE_SA, not
   the IP header of the IKEv2 message requesting the IPsec SA.  The
   addresses in the IKE_SA are initialized from the IP header of the
   first IKE_AUTH request.

In other words: the CREATE_CHILD_SA request is not rejected, and 
the reply is still sent back to the address the packet came from;
but the tunnel endpoints are initialized from stored information
(which can be updated by UPDATE_SA_ADDRESSES).

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 7 Nov 2007 16:12:07 +0200

Chinh Nguyen writes:
> A IKEv2 peer may choose to reject a CREATE_CHILD_SA if it arrives from 
> an "unknown" endpoint (SPIs + src/dst addresses are used to track IKEv2 
> exchanges). In such case, the CREATE_CHILD_SA will fail if a. the 
> CREATE_CHILD_SA arrives before the UPDATE_SA exchange or b. the 
> CREATE_CHILD_SA arrives while the peer is doing a route check to 
> complete the UPDATE_SA exchange.

With proper mobike implementations there should not be any such
problems. The outer addresses should not be used for policy
enforcements, as it is using valid IKE SA to send that
CREATE_CHILD_SA. If the CREATE_CHILD_SA arrives while doing return
routability check, that should not cause any problems either. 

> However, this can be mitigated by having the IKEv2 peer use only the 
> SPIs to track IKEv2 exchanges and ignore src/dst addresses.

If you are using mobike, you do ingore outer src/dst addresses
anyways (or at least do not use them to enforce any kind of policy,
you of course use them to detect movement etc). 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 7 Nov 2007 16:24:03 +0200

> which the IKE_SA is currently tied - is that not true?  RFC4306 is not

Check the RFC4555 instead of RFC4306. With mobike all existing IPsec
SAs do get updated with new outer addresses with UPDATE_SA_ADDRESSES,
so it does not matter what the outer IP adresses were when the IPsec
SA was created. Also it is normal operation to get packets in with
different outer address to IKE SA when using MOBIKE. This happens for
example when you start to do UPDATE_SA_ADDRESSES, but can happen also
with any other IKEv2 packet. This is because other end might not be
able to send UPDATE_SA_ADDRESSES because it first needs to finish
other ongoing exchange on the IKEv2 SA in case the window size is only
1. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike