headers
Mohan Parthasarathy | 1 Sep 2005 03:09
Picon
Favicon

Re: RE: issue 34 -- ESP vs. IKE based NAT reboot detection


> Tero Kivinen wrote:
> 
> >Thats why I am saying alternate 3 is better, as it requires less
> >changes or updates to the hardware.
> >  
> >
> One could also support ESP-based updates on devices
> that can do this, and say "this feature is not supported"
> on others -- we are still talking about a corner case.
> But people may have different opinions as to how
> important support for this is under all circumstances.
> 
If you do IKEv2 like updates, then you need a separate PATH_TEST
message (outside the SA) so that PATH_TEST does not cause updates
to SA. By requiring an explicit update, we avoid a separate PATH_TEST
message. Is that an advantage ?

-mohan

> --Jari
> 
> _______________________________________________
> Mobike mailing list
> Mobike <at> machshav.com
> https://www.machshav.com/mailman/listinfo.cgi/mobike
Permalink | Reply | 1 comment |
headers
Shinta Sugimoto | 1 Sep 2005 08:47
Picon

Re: Issue 38: editorial comments (was: comments on draft-ietf-mobike-protocol-01.txt)

Hello Pasi,

Thank you for the clarification.

On Wed, 31 Aug 2005 14:36:09 +0300
<Pasi.Eronen <at> nokia.com> wrote:

> 
> Thanks for your comments! I've filed them as issues 38 and 39.
> Quick answers to your editorial comments first:
> 
> > - Section 2.3 (Changing addresses in IPsec SAs), 3rd bullet,
> > it says "If there are outstanding IKEv2 requests, continues
> > retransmitting them using the addresses in the IKE_SA (the new
> > addresses)." It is unclear to me what the "outstanding IKEv2
> > requests" are.
> 
> It means IKEv2 requests for which the initiator has not yet
> received a reply (I'll try to clarify this in version -02).
> This could happen if the need to change addresses appears 
> while we're doing e.g. rekeying or dead peer detection.

OK, understood.

Regards,
Shinta
Permalink | Reply | 501 comments |
headers
Shinta Sugimoto | 1 Sep 2005 09:07
Picon

Re: issue 39 (was: comments on draft-ietf-mobike-protocol-01.txt)

Hello again,

On Wed, 31 Aug 2005 16:06:31 +0300
<Pasi.Eronen <at> nokia.com> wrote:

> Shinta Sugimoto writes:
> > 
> > Hello,
> > 
> > I read draft-ietf-mobike-protocol-01.txt and had following
> > comments/questions.
> > 
> > Technical Comments/Questions:
> > 
> > - Section 2.3 (Changing addresses in IPsec SAs) I need
> > clarification on how address change functions in MOBIKE. First
> > of all, does UPDATE_SA_ADDRESSES take effect on more than one
> > address changes ?  Or it's supposed to update a single address? 
> 
> It updates the one source and one destination address in
> IKE and IPsec SAs (the src/dst addresss that is currently
> used for outgoing packets).

OK.

> > Probably I am confusing the purpose of UPDATE_SA_ADDRESSES
> > and ADDITIONAL_*_ADDRESS.  In my understanding,
> > UPDATE_SA_ADDRESSES is for updating the preferred address,
> > which means that IKE_SA and IPsec SA (only matched one) are
> > the target of the address update. OTOH, ADDITIONAL_*_ADDRESS
(Continue reading)

Permalink | Reply | 501 comments |
headers
Tero Kivinen | 1 Sep 2005 10:35
Picon
Picon
Favicon

Re: RE: issue 34 -- ESP vs. IKE based NAT reboot detection

Mohan Parthasarathy writes:
> > One could also support ESP-based updates on devices
> > that can do this, and say "this feature is not supported"
> > on others -- we are still talking about a corner case.
> > But people may have different opinions as to how
> > important support for this is under all circumstances.
> > 
> If you do IKEv2 like updates, then you need a separate PATH_TEST
> message (outside the SA) so that PATH_TEST does not cause updates
> to SA. By requiring an explicit update, we avoid a separate PATH_TEST
> message. Is that an advantage ?

I think it is advantage, if we do not need to implement separate
PATH_TEST. It makes the protocol cleaner. The separate PATH_TEST has a
feeling of a hack for me. 

Also it will localize the policy decisions on the IP-address changes
to one place, so the policy will be same regardless why we change the
address.
--

-- 
kivinen <at> safenet-inc.com
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 1 Sep 2005 14:27
Picon

RE: RE: issue 34 -- ESP vs. IKE based NAT reboot detection

Mohan Parthasarathy wrote:

> If you do IKEv2 like updates, then you need a separate PATH_TEST
> message (outside the SA) so that PATH_TEST does not cause updates to
> SA. By requiring an explicit update, we avoid a separate PATH_TEST
> message. Is that an advantage ?

Actually, we need a separate PATH_TEST message even with the explicit
update if we want to be able to do path testing at any time without
the possibility of disrupting things.

(And IMHO having a separate path test message that does nothing else
would also make MOBIKE easier to understand, even though it may
require a couple of more lines in code.)

Best regards,
Pasi
Permalink | Reply | 2 comments |
headers
Stephane Beaulieu (stephane | 1 Sep 2005 14:50
Picon
Favicon

RE: RE: issue 34 -- ESP vs. IKE based NAT reboot detection

I would prefer to avoid sending periodic probes (option 3).

Even though the HW may not be capable of detecting and performing
IP/port changes *today*, they will be able to do it in the future
(especially if we make it a requirement for them).

It's not like if Mobike is going to be mass deployed tomorrow.  This is
going to take a long time to bake and test.  Start working with your HW
vendors now, and let's do it right the first time.  Those who ship
before the HW is ready can document this corner case, or solve it via
some less efficient SW workaround (for now).  I'd rather take the
performance hit for BETA than forever...

I vote option 1.
Stephane.

> -----Original Message-----
> From: mobike-bounces <at> machshav.com 
> [mailto:mobike-bounces <at> machshav.com] On Behalf Of Jari Arkko
> Sent: Thursday, August 25, 2005 6:03 AM
> To: Tero Kivinen
> Cc: Pasi.Eronen <at> nokia.com; Mohan Parthasarathy; mobike <at> machshav.com
> Subject: Re: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT 
> reboot detection
> 
> Tero Kivinen wrote:
> 
> >Thats why I am saying alternate 3 is better, as it requires less 
> >changes or updates to the hardware.
> >
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tero Kivinen | 1 Sep 2005 14:52
Picon
Picon
Favicon

RE: RE: issue 34 -- ESP vs. IKE based NAT reboot detection

Pasi.Eronen <at> nokia.com writes:
> Actually, we need a separate PATH_TEST message even with the explicit
> update if we want to be able to do path testing at any time without
> the possibility of disrupting things.

You mean the case, where we have decided to move to new address, but
that new address breaks down after us testing it and after we sent
update to it, but before we get reply back to it? I think we do not
disrupt things more even if we use the IKE SA update message for
testing the path. The path is already broken, so we cannot disrupt it
more. After we get the IKE SA update message through, we have then
already fixed the situation, with separate path test we still need to
wait one more extra round trip to fix the situation (i.e we first use
the PATH_TEST to find the working path, and then send the packet to
that address, compared to using the IKE SA update message to do the
path test, and that will immediately fix the situation when the
correct path is found (or in case of unidirectional paths, then we
need to wait the another round trip, i.e. for the second address
update to reach the host)). 
--

-- 
kivinen <at> safenet-inc.com
Permalink | Reply | 1 comment |
headers
Jari Arkko | 1 Sep 2005 14:56

Re: Issue 36: unacceptable addresses (was: confirming consensus on issues from Paris)

Pasi.Eronen <at> nokia.com wrote:

>Jari Arkko wrote:
>
>  
>
>>Issue 36: Unacceptable addresses. There are cases where the
>>initiator does not know which one of the retransmitted
>>requests was really the one seen by the responder and resulted
>>in the unacceptable address error. Pasi's solution for this is
>>to send a new request in this (corner) case.
>>    
>>
>
>(Back from vacation, and working on MOBIKE again...)
>
>I started editing the draft to make this change, but then
>noticed the functionality is actually already there. Version
>-01 says
>
>   o  If a new address change occurs while waiting for the 
>      response, starts again from the first step (and ignores 
>      responses to this UPDATE_SA_ADDRESSES request).
>
>So in the ambiguous situation (UPDATE_SA_ADDRESSES request has
>been sent using several different src/dst addresses, and we
>don't know which of them was unacceptable), it already says
>we ignore the response and a new request is sent.
>
>(But I'll clarify this in -02; also the response is not really
(Continue reading)

Permalink | Reply | 501 comments |
headers
Pasi.Eronen | 1 Sep 2005 15:05
Picon

RE: RE: issue 34 -- ESP vs. IKE based NAT reboot detection

Stephane Beaulieu wrote:
> 
> I would prefer to avoid sending periodic probes (option 3).

Note that these periodic probes are already present in normal
IKEv2; option 3 just piggy-backs additional information (NAT
detection payloads) to the same messages.

> Even though the HW may not be capable of detecting and
> performing IP/port changes *today*, they will be able to do it
> in the future (especially if we make it a requirement for
> them).
> 
> It's not like if Mobike is going to be mass deployed tomorrow.
> This is going to take a long time to bake and test.  Start
> working with your HW vendors now, and let's do it right the
> first time.  Those who ship before the HW is ready can
> document this corner case, or solve it via some less efficient
> SW workaround (for now).  I'd rather take the performance hit
> for BETA than forever...
> 
> I vote option 1.

Since the same messages are sent in normal IKEv2 as well, 
option 3 has a performance hit (on gateway load) only if 
choosing it causes the users to change the timer values
for DPD ("X" in my IETF63 slides; essentially how long to
accept a situation where we have only outgoing traffic before
getting suspicious and starting DPD).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tero Kivinen | 1 Sep 2005 15:07
Picon
Picon
Favicon

RE: RE: issue 34 -- ESP vs. IKE based NAT reboot detection

Stephane Beaulieu \(stephane\) writes:
> I would prefer to avoid sending periodic probes (option 3).

We are sending them anyways if there is no traffic (IKE SA dead peer
detection). The difference is that in option 1 those probes are only
used to detect if the other peer is alive, and in option 3 they also
make sure that the other end the correct NAT-T mapping in addition to
test that the other peer is alive. The amount and timers for those
packets should be same, but Pasi was little bit concerned that some
adminstrators might want to configure the timers shorter in case we
select option 3 to allow faster recovery of lost NAT mappings. I
myself thing that this is such corner case that I do not think anybody
will configure the timers shorter because of that.

The option 3 packets will be few bytes bigger than the option 1
packets, but actually the size difference is lost in the padding (at
least for AES cipher). Both of them are small, i.e. about 100 bytes
(ip 20 + udp 8 + ike 28 + encr header 4 + iv 16 + empty or 8 byte
notify plus padding 16 + 12).

In addition to that IKE SA dead peer detection payloads, there is the
normal NAT-T keepalive packets going on, which are again same in both
option 1 and 3.
--

-- 
kivinen <at> safenet-inc.com
Permalink | Reply | 2 comments |

Gmane