Subject: RE: [Mobike] issue 11 -- window size

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 11 May 2005 10:15:46 -0700 (PDT)

--- Tero Kivinen <[email-masked]> wrote:
> [email-masked] writes:
> > I think it is useful to allow path testing even
> when the current
> > path is working, and the protocol should support
> doing this 
> > without disrupting ongoing communication (which
> does not seem
> > to be possible in your proposal).
> 
> It is possible, the protocol just needs to be
> written so it supports
> it. If you want to get it working with IKEv2 NAT-T
> you need to add
> modify the NAT-T behavior when using MOBIKE little
> more (You need to
> modify the NAT-T behavior in all cases)
>  
> > (E.g., suppose we have two interfaces, one very
> fast and cheap, 
> > second one very slow and expensive. If the first
> one has a temporary 
> > problem, and we switch to the second one, we want
> to switch back 
> > when possible even if the second interface keeps
> on working forever.)
> 
> Then you simply say that only N(MOVE TRAFFIC) is the
> only method of
> updating the addresses. I.e. disable dynamic
> updating of IKEv2 NAT-T
> (it is already allowed as dynamic update is SHOULD
> not MUST). 

I agree that this is one possibility i.e if the peer
has indicated MOBIKE support, then disable NAT-T like
updates. Expect that the peer will explicitly update
the addresses.

To some extent, this is needed even when PATH_TEST
message is a separate message i.e when the PATH_TEST
is processed, you don't update the addresses of the
SAs yet. Somehow this looks cleaner to me :-)

If there are several paths and some of them contains
NAT, i am assuming that Tero's proposal can detect
them (inspite of the constraint that the retransmitted
message cannot be modified). If this is getting into
too much detail, i will wait :-)

-mohan

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 May 2005 10:54:12 +0300

> too much detail, i will wait :-)

Yes, the initiator can detect NAT, as the responder will not try any
other addresses, i.e. it always replies back to the address where
addresess are reversed.

This simply requires that we want to have option to turn NAT-T on /
off as a separate notify, as requested by initiator after detecting
NAT (and after consulting policy etc). 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 May 2005 11:17:00 +0300

>NAT (and after consulting policy etc). 
Ok. And doing this separately works, because the IKEv2
messages will always go through NATs and because the
peer responds back to the same address/port combination,
right? Its only the ESP traffic for which the specific NAT
support needs to be turned on.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 12 May 2005 12:03:07 +0300

> support needs to be turned on.

Yes. I.e. ESP traffic that is moved to the path that has NAT, needs to
be UDP-encapsulated.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike