headers
Tschofenig Hannes | 6 Dec 2004 10:16
Picon

Zero Address Set

hi all, 

i thought about the functionality of the "zero address set". one important
question is: what is this functionality good for? 

draft <draft-kivinen-mobike-protocol-00.txt> says:
"
seconds how long the peer assumes to be disconnected
"

pasi calls this functionality (in draft <draft-eronen-mobike-mopo-01.txt>):

"
 temporarily forwarding the traffic of some SA to /dev/null
"

draft <draft-ietf-mobike-design-00.txt> is more verbose on this issue:

"
   One of the features which might be useful would be for the peer to
   announce the other end that it will now disconnect for some time,
   i.e. it will not be reachable at all. For instance, a laptop might go
   to suspend mode. In this case the peer could send address
   notification with zero new addresses, which means that it will not
   have any valid addresses anymore. The responder of that kind of
   notification would then acknowledge that, and could then temporarily
   disable all SAs. If any of the SAs gets any packets they are simply
   dropped. This could also include some kind of ACK spoofing to keep
   the TCP/IP sessions alive (or simply set the TCP/IP keepalives and
   timeouts large enough not to cause problems), or it could simply be
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tschofenig Hannes | 6 Dec 2004 10:16
Picon

RE: issue 4: how to signal support for MOBIKE

hi all, 

i went thought about the two most important options: notify and vendor id

they both seem to provide the same capability. notify is used for errors but
also for indicating sender capabilities. the same is true for the vendor id.

as a text proposal i suggest to enhance the text offered by jari as follows:

-----------------------

X. Indicating Support for MOBIKE

A node needs to be able to guarantee that its address change messages are
understood by the peer. Otherwise an address change may render the
connection useless, and it is important that both sides realize this as
early as possible.

Ensuring that the messages are understood can in be arranged either by
marking some IKEv2 payloads critical so that they are either processed or an
error message is returned, by using Vendor ID payloads or via a Notify. 

The first solution approach is to use Vendor ID payloads during the initial
IKEv2 exchange using a specific string denoting MOBIKE to signal the support
of the MOBIKE protocol. This ensures that in all cases a MOBIKE capable node
knows whether its peer supports MOBIKE or not. 

The second solution approach uses the Notify payload which is also used for
NAT detection (via NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP), .
(Continue reading)

Permalink | Reply | 504 comments |
headers
Tschofenig Hannes | 6 Dec 2004 10:16
Picon

RE: issue 10: changing addresses or paths?

hi jari, 

i agree with you that we need to test paths rather than addresses. i have
read your multi6 draft
<http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-
00.txt> which also derives this conclusion. 

my personal experience with path-coupled signaling in the nsis environment
also supports this observation.

ciao
hannes

> Our earlier resolution of issue 17 (if both parties have 
> several addresses, do we assume that all pairs have 
> connectivity between them?) was that we should NOT assume 
> full connectivity in these cases.
> 
> I believe the above resolution implies that upon a problem, 
> we may have to switch paths, not just an address. I also 
> explained the issue in Washington in my presentation.
> 
> So I think its pretty clear that the answer to this question 
> is that we need to be able to change paths.
> Suggested text below:
> 
> Change design draft from
> 
> 6.  Changing addresses or changing the paths (issue #10, #14)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tschofenig Hannes | 6 Dec 2004 12:02
Picon

issue 3: nat traversal

hi all, 

let us try to close the nat traversal issue (issue 3) from 
http://www.vpnc.org/ietf-mobike/issue3.txt

here is what we currently have: 

- charter says that we should not modify the ikev2 nat traversal mechanism.
none of the proposal tries to todo that. 
- draft <draft-eronen-mobike-simple-00.txt> addresses nat traversal. 
- draft <draft-eronen-mobike-mopo-01.txt> and
<draft-dupont-ikev2-addrmgmt-06.txt> additionally add a mechanism to
indicate nat traversal prevention.

a number of people pointed to the need to support nat traversal. 

hence, i think that we could have support for
- nat traversal and
- a nat traversal prevention (if you think you don't need it)
without conflicting with the charter.  

to address the scenarios there also needs to support for an end host moving
from not-behind a nat to behind a nat.  

ciao
hannes
Permalink | Reply | 5 comments |
headers
Tschofenig Hannes | 6 Dec 2004 13:02
Picon

When to do Return Routability Checks

hi all, 

i would like to close the 'When to do Return Routability Checks' issue
(which can be found at: 
http://www.vpnc.org/ietf-mobike/issue6.txt)

please take a look at previous text in the design document on this issue: 

"
3.2 When to do Return Routability Checks

   One of the decisions that needs to be done, when to do return
   routability checks. The simple approach is to do it always. 
                                                      ^^^^^^^^
[hannes] 'always' is not very precise. 

 Another
   option is to do it every time new IP-address is taken in to use.

[hannes] jari introduces useful terminology relevant for this sentence in
<draft-arkko-multi6dt-failure-detection-00.txt>. we might want to use some
of it in mobike. 

 The
   basic format of the return routability check could be similar than
   dead-peer-detection, but the problem is that if that fails then the
   IKEv2 specification requires the IKE SA to be deleted. Because of
   this we might need to do some kind of other exchange.

   If the other end is SGW with limited set of fixed IP-addresses, then
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tschofenig Hannes | 6 Dec 2004 17:42
Picon

issue 1: direct or indirect indicators

hi all, 

i would like to discuss issue #1: 
http://www.vpnc.org/ietf-mobike/issue1.txt

the current text on this issue says: 
--------------------

[Comment from secretary: TEMP-draft-kivinen-mobike-protocol-00.txt has
both direct indications (peer explicitly requests change) and indirect
based on address lists (when current address seems to have stopped
working, try others). draft-dupont-ikev2-addrmgmt-04.txt also has
both.]

--------------------

here are some basic observations:

you need to have more than one address anyway to switch to another one. 

it depends which entity detects the problem first. 

if the initiator detects that there is a problem (e.g., on the local link)
then it can switch to a new address. sending an ikev2 notification message
from the new address to the responder is fine and might cause an address
update of the ipsec sa with or without return routability check
(authorization decision). 

if the responder detects that there was a problem (e.g., on its local link)
then it might want to send the initiator a notification that it should use a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Sommerfeld | 6 Dec 2004 17:56
Picon

Re: Zero Address Set

On Mon, 2004-12-06 at 04:16, Tschofenig Hannes wrote:

> i thought about the functionality of the "zero address set". one important
> question is: what is this functionality good for? 

temporary tunnel suspension when the endpoint knows it will be unreachable  for a while.

> i see this issue from a different point of view.
> we have a dead peer detection to provide a mechanism to delete the ike sa
> (and ipsec sas) if the other does not respond anymore. 

well, let's distinguish two cases:
 1) we haven't heard from the peer in a while.
 2) the peer has crashed and forgot about the connection

For some applications, tearing down state because of (1) may rightly viewed  as a bug, not a feature -- but you
may want fast recovery from (2) without 
tearing down connections merely because of inactivity.

> if a laptop has establish an ike sa with a gateway, uses dead peer detection
> and goes into the suspend mode then (even after a short amount of time) the
> ike sa will be gone. 
> 
> the 'zero address set' functionality could possibly be seen as temporarily
> suspending the dead peer protection on a specific address (or path). 

Sorta.

						- Bill
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tschofenig Hannes | 6 Dec 2004 18:06
Picon

RE: Zero Address Set

hi bill, 

thanks for your quick response. the term 'zero address set' is quite
confusing but i tend to agree with the discussions on the mailing list which
came to the conclusion that this feature should not incorporated into a
mobike protocol. 

the desire to check connectivity (via some sort of message exchange)
periodically has the unpleasant(?) effect that the ike/ipsec sa will be
deleted if one of the peers is not reachable anymore. 

ciao
hannes

> On Mon, 2004-12-06 at 04:16, Tschofenig Hannes wrote:
> 
> > i thought about the functionality of the "zero address set". one 
> > important question is: what is this functionality good for?
> 
> temporary tunnel suspension when the endpoint knows it will 
> be unreachable  for a while.
> 
> > i see this issue from a different point of view.
> > we have a dead peer detection to provide a mechanism to 
> delete the ike 
> > sa (and ipsec sas) if the other does not respond anymore.
> 
> well, let's distinguish two cases:
>  1) we haven't heard from the peer in a while.
>  2) the peer has crashed and forgot about the connection
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mohan Parthasarathy | 6 Dec 2004 19:05
Picon
Favicon

Re: issue 3: nat traversal

Hannes,

> let us try to close the nat traversal issue (issue 3) from 
> http://www.vpnc.org/ietf-mobike/issue3.txt
> 
> here is what we currently have: 
> 
> - charter says that we should not modify the ikev2 nat traversal mechanism.
> none of the proposal tries to todo that. 
> - draft <draft-eronen-mobike-simple-00.txt> addresses nat traversal. 
> - draft <draft-eronen-mobike-mopo-01.txt> and
> <draft-dupont-ikev2-addrmgmt-06.txt> additionally add a mechanism to
> indicate nat traversal prevention.
> 
> a number of people pointed to the need to support nat traversal. 
> 
The issue is a bit confusing to me. I agree that we don't want to modify
the IKEv2 NAT traversal as specified in the IKEv2 draft. But do we want
MOBIKE to work when moving behind NATs ? I am not sure which
question is being asked here. Could you clarify ? I see this as two separate
things. If we want to track this as two separate issues, i am fine with that.

-mohan

> hence, i think that we could have support for
> - nat traversal and
> - a nat traversal prevention (if you think you don't need it)
> without conflicting with the charter.  
> 
> to address the scenarios there also needs to support for an end host moving
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dondeti, Lakshminath | 6 Dec 2004 19:16

Re: When to do Return Routability Checks


Tschofenig Hannes wrote:

> hi all,
>
> i would like to close the 'When to do Return Routability Checks' issue
> (which can be found at:
> http://www.vpnc.org/ietf-mobike/issue6.txt)
>
> please take a look at previous text in the design document on this issue:
>
> "
> 3.2 When to do Return Routability Checks
>
>    One of the decisions that needs to be done, when to do return
>    routability checks. The simple approach is to do it always.
>                                                       ^^^^^^^^
> [hannes] 'always' is not very precise.
>
>  Another
>    option is to do it every time new IP-address is taken in to use.
>
> [hannes] jari introduces useful terminology relevant for this sentence in
> <draft-arkko-multi6dt-failure-detection-00.txt>. we might want to use 
> some
> of it in mobike.
>
>  The
>    basic format of the return routability check could be similar than
>    dead-peer-detection, but the problem is that if that fails then the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane