Subject: [IPsec] New Version Notification for draft-intoto-simple-mobility-ipsec-clients-00

From: ns srinivasa murthy <[email-masked]>
Date: Tue, 20 May 2008 12:59:38 +0530

Hi all,
Please send your comments.
Thanks
-nsmurthy

A new version of I-D, 
draft-intoto-simple-mobility-ipsec-clients-00.txt has been 
successfuly submitted by Srinivasa Murthy and posted to the IETF repository.

Filename:       draft-intoto-simple-mobility-ipsec-clients
Revision:       00
Title:          Simple Mobility Solution for IPsec Clients
Creation_date:  2008-05-18
WG ID:          Independent Submission
Number_of_pages: 7

Abstract:
One very popular use of VPNs is to provide telecommuter access to
the corporate Intranet. Remote clients that are behind NAT boxes
can also access the corporate intranet with the help of the
standard NAT Traversal feature.

But this access may be disturbed in scenarios where a mobile user
roams across different points of attachment and there by getting
assigned with different IP Addresses. The access also fails in
cases where the client roams across environments with NAT
to environments without NAT and vice versa. In both the cases
the tunnel may get re-established but it induces jitter in voice
sessions.

The IETF Secretariat.

********************************************************************************
This email message (including any attachments) is for the sole use of the intended recipient(s) 
and may contain confidential, proprietary and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you are not the intended recipient, 
please immediately notify the sender by reply email and destroy all copies of the original message. 
Thank you.
 
Intoto Inc. 

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 May 2008 11:35:35 +0300

Hi

I think this draft may be very useful, and I have a few comments:

1. NAT Detection payloads, as defined in the relevant RFCs have a  
payload that is the output of a SHA-1 function, so the payload length  
is 28 bytes. Implementations will verify this length as part of a  
packet sanity check.  I suggest that you keep the payload with length  
28, and fill it with something random-looking rather than sending a  
zero length payload.  You may even want to specify a 20-byte string  
(maybe the SHA-1 hash of "draft-intoto-simple-mobility-ipsec-clients").

2. There is no signaling in the protocol of compliance with this  
specification.  Section 4 of your draft details some gateway behavior,  
but a compliant client has no way of knowing whether the gateway is  
compliant.

Suppose I were now writing a client that should connect to any RFC4306- 
compliant gateway, but does not support MOBIKE. I might use a protocol  
such as STUN to detect when my IP address changes. When that happens,  
I would begin an INITIAL exchange, and tear down the previous tunnel.  
That would give me a working tunnel as quickly as possible. This is  
more cumbersome, but is necessary where gateways don't implement your  
draft.

If some of the gateways in the world support your attribute, while  
some don't, clients need a way to tell them apart.  A notification  
(SIMPLE-MOBILITY-SUPPORTED) could help here.

Yoav

On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote:

> A new version of I-D, draft-intoto-simple-mobility-ipsec- 
> clients-00.txt has been successfuly submitted by Srinivasa Murthy  
> and posted to the IETF repository.
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 20 May 2008 14:53:55 +0300

One more: when a client detects that it has moved (e.g. it has a new IP 
address), it is important that it signals this fact, instead of waiting 
for the next "real" traffic to be sent over the tunnel. Otherwise the 
gateway will not know about the address change and the client will not 
be reachable from the network side, possibly for a long time. One option 
is for the client to generate a DPD message. RFC 4555, Sec. 2.1 has more 
background about movement detection.

Thanks,

    Yaron

Yoav Nir wrote:

> Suppose I were now writing a client that should connect to any 
> RFC4306-compliant gateway, but does not support MOBIKE. I might use a 
> protocol such as STUN to detect when my IP address changes. When that 
> happens, I would begin an INITIAL exchange, and tear down the previous 
> tunnel. That would give me a working tunnel as quickly as possible. 
> This is more cumbersome, but is necessary where gateways don't 
> implement your draft.
>
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: ns srinivasa murthy <[email-masked]>
Date: Wed, 21 May 2008 11:04:24 +0530

Thanks for the feedback.Please find my responses embedded with nsmurthy>

-nsmurthy

At 02:05 PM 5/20/2008, Yoav Nir wrote:
>payload that is the output of a SHA-1 function, so the payload 
>length is 28 bytes. Implementations will verify this length as part 
>of a packet sanity check.  I suggest that you keep the payload with 
>length 28, and fill it with something random-looking rather than 
>sending a zero length payload.  You may even want to specify a 
>20-byte string (maybe the SHA-1 hash of 
>"draft-intoto-simple-mobility-ipsec-clients").

nsmurthy>
My idea was to keep the payload length at 28 only but fill it up with 
zeroes to avoid any remote possibility of a match.

>specification.  Section 4 of your draft details some gateway 
>behavior, but a compliant client has no way of knowing whether the 
>gateway is compliant.
>
>RFC4306-compliant gateway, but does not support MOBIKE. I might use 
>a protocol such as STUN to detect when my IP address changes. When 
>that happens, I would begin an INITIAL exchange, and tear down the 
>previous tunnel. That would give me a working tunnel as quickly as 
>possible. This is more cumbersome, but is necessary where gateways 
>don't implement your draft.
>

nsmurthy>
Yes you are right.In case of IKEv2,a 
notification             (SIMPLE-MOBILITY-SUPPORTED) can be sent in 
messages 3 and 4 to announce the support.

>><mailto:[email-masked]>[email-masked]

Intoto Inc.

---

From: ns srinivasa murthy <[email-masked]>
Date: Wed, 21 May 2008 11:13:44 +0530

The draft listed this as a limitation and it assumes that "packets 
from server are lost until client sends atleast one packet with the
new IP Address".

To overcome this ,the client can send a notification with an empty 
payload whenever its IP Address changes.The notification pay load may 
be just empty as the server adapts the IP Address from the packet it received.

Thank you
-nsmurthy

At 05:23 PM 5/20/2008, Yaron Sheffer wrote:

>One more: when a client detects that it has moved (e.g. it has a new 
>IP address), it is important that it signals this fact, instead of 
>waiting for the next "real" traffic to be sent over the tunnel. 
>Otherwise the gateway will not know about the address change and the 
>client will not be reachable from the network side, possibly for a 
>long time. One option is for the client to generate a DPD message. 
>RFC 4555, Sec. 2.1 has more background about movement detection.
>
>
>Thanks,
>
>     Yaron
>
>
>Yoav Nir wrote:
>>Hi
>>

Intoto Inc.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 May 2008 10:12:25 +0300

An empty informational with no payloads is exactly what's called a  
"liveness check" in IKEv2 and sometimes called DPD.

On May 21, 2008, at 8:43 AM, ns srinivasa murthy wrote:

> payload whenever its IP Address changes.The notification pay load  
> may be just empty as the server adapts the IP Address from the  
> packet it received.
>
> Thank you
> -nsmurthy
>
>> One more: when a client detects that it has moved (e.g. it has a  
>> new IP address), it is important that it signals this fact, instead  
>> of waiting for the next "real" traffic to be sent over the tunnel.  
>> Otherwise the gateway will not know about the address change and  
>> the client will not be reachable from the network side, possibly  
>> for a long time. One option is for the client to generate a DPD  
>> message. RFC 4555, Sec. 2.1 has more background about movement  
>> detection.
>>
>>
>> Thanks,
>>
>>     Yaron
>>
>>
>> Yoav Nir wrote:
>>> Hi
>>>
>>> length is 28 bytes. Implementations will verify this length as  
>>> part of a packet sanity check.  I suggest that you keep the  
>>> payload with length 28, and fill it with something random-looking  
>>> rather than sending a zero length payload.  You may even want to  
>>> specify a 20-byte string (maybe the SHA-1 hash of "draft-intoto- 
>>> simple-mobility-ipsec-clients").
>>>
>>> RFC4306-compliant gateway, but does not support MOBIKE. I might  
>>> use a protocol such as STUN to detect when my IP address changes.  
>>> When that happens, I would begin an INITIAL exchange, and tear  
>>> down the previous tunnel. That would give me a working tunnel as  
>>> quickly as possible. This is more cumbersome, but is necessary  
>>> where gateways don't implement your draft.
>>>
> Scanned by Check Point Total Security Gateway.
>
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 May 2008 10:17:03 +0300

On May 21, 2008, at 8:34 AM, ns srinivasa murthy wrote:

>> sending a zero length payload.  You may even want to specify a 20- 
>> byte string (maybe the SHA-1 hash of "draft-intoto-simple-mobility- 
>> ipsec-clients").
>
> nsmurthy>
> My idea was to keep the payload length at 28 only but fill it up  
> with zeroes to avoid any remote possibility of a match.

In that case, I suggest clarify that in the next version. Also it's  
possible to use an all-zeros NAT detection as an indication of   
protocol support.

Yoav