Subject: RE: [Mobike] New issue 16: No packets from other end?

From: <[email-masked]>
Date: Tue, 12 Oct 2004 20:49:19 +0300

[email-masked] writes:
>> 
>> BTW, if we were adding MOBIKE to IKEv1, nothing extra would be 
>> needed in the protocol to allow hosts to handle this "no packet 
>> from other end" case; the R-U-THERE dead peer detection messages 
>> [RFC3706] would be enough.
>>    
>> But currently it seems (to me at least) that in IKEv2, the ability 
>> to send some kind of R-U-THERE/Hello/Ping/Heartbeat/Path test
>> messages outside the IKEv2 window would be necessary, or at 
>> would simplify the protocol considerably. (And since we decided 
>> not to assume full connectivity, something like that message may 
>> be needed anyway.)
>    
> Pasi, I understand your reasonning but not its conclusion.

I'm not totally sure about the conclusion myself, but I'll try 
to clarify my reasoning a bit. Consider the following situation:

- Both peers (A and B) have several addresses (A1,A2,...An,
  B1,B2,...Bn)

- We don't have full connectivity: there are some (i,j) 
  for which using Ai,Bj does not provide connectivity  
  between the IKEv2 endpoints (that is, IKEv2 
  implementations running on hosts A and B).

- Host A receives some kind of indication (beyond the scope 
  of MOBIKE) that its current address (say, A1) is likely to 
  stop working soon.

- Since we don't have full connectivity, A's "mobility and 
  multihoming control module" would like to find the best 
  working (Ai,Bj) before the current one stops working.

- In general, lower-layer mechanisms cannot tell whether pair
  (Ai,Bj) provides connectivity between the IKEv2 endpoints:
  only an IKEv2 message exchange can tell that.

- If we have a separate R-U-THERE message (without window
  size restrictions), A's "mobility and multihoming control 
  module" could just ask the "MOBIKE module" to try whether
  some (Ai,Bj) works without worrying about interfering with
  anything else IKEv2 might be doing.

- We can't in general just send a new IKEv2 informational 
  exchange request, because there might be a pending
  request already (and this is the crucial difference 
  to IKEv1). And just waiting until we get a reply to 
  the pending request does not work either if getting
  a reply depends on us doing something before that.

- In some earlier protocol sketch I suggested just sending
  the most recent IKE request as a test packet: the other 
  end will retransmit its reply if that (Ai,Bj) works.
  But it turned out that this can in fact interfere
  with other functionality, such as return routability 
  checks and "NAT prevention" payloads in some circumstances 
  (if the original request packet got lost).

It's possible that this icould be solved by some other
means than introducing a "non-window-restricted" message...
but it might be the simplest solution.

(In particular, I'm not happy with the idea of assuming --- 
totally contrary to the end-to-end principles --- that the 
"mobility and multihoming module" knows or can figure out 
connectivity between IKEv2 endpoints without sending IKEv2
messages.)  

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Oct 2004 22:58:28 +0300

Hello all,

While we have not found agreement yet, I think this is
a very useful discussion. I believe that when we come to
the conclusion we have come a long way towards agreeing
what MOBIKE protocol is...

Let me attempt a few definitions that may ease the
discussion.

Here's an overview, details at the end of the mail:
Basically, I think that we have something
called Available Addresses, delivered to MOBIKE from
IPv6/DNA etc. As far as I can see, no one in the WG
is thinking of using MOBIKE mechanisms for this.

I'd also like to distinguish between locally operational
and non-operational addresses; you can have an address
but for some reason you know that it isn't working. For
instance, the default router is down. I don't see MOBIKE
doing anything for this either, we already IPv6 and other
mechanisms for this.

Finally, what really matters for MOBIKE is an address pair, and
whether communication using that address pair is possible. This
is only possible if the two addresses are locally operational
AND there's IP connectivity between them. The latter is what we
are currently debating: do we expect the connectivity to be
tested and the best pair chosen by MOBIKE or something else?

Details:

1.  Available Addresses

    MOBIKE nodes need to be aware of what addresses they themselves have.
    If a node loses the address it is currently using for communications,
    another address must replace this address. And if a node loses an
    address that the node's peer knows about, the peer must be informed.
    Similarly, when a node acquires a new address it may generally wish
    the peer to know about it.

    Definition. Available address. An address is said to be available if
    the following conditions are fulfilled:

    o  The address has been assigned to an interface of the node.

    o  If the address is an IPv6 address, we additionally require that
       (a) the address is valid in the sense of RFC 2461, and that
       (b) the address is not tentative in the sense of RFC 2462.  In
       other words, the address assignment is complete so that
       communications can be started.

       Note this explicitly allows an address to be optimistic in the
       sense of [draft-ietf-ipv6-optimistic-dad] even though
       implementations are probably better off using other
       addresses as long as there is an alternative.

    o  The address is a global unicast or unique site-local address
       [draft-ietf-ipv6-unique-local-addr].

       That is, it is not an IPv6 link-local or site-local address.
       Where IPv4 is considered, it is not an RFC 1918 address.

    Available addresses are discovered and monitored through mechanisms
    outside the scope of MOBIKE.  These mechanisms include IPv6
    Neighbor Discovery and Address Autoconfiguration [RFC 2461-2462],
    DHCP [RFC 3315], enhanced network detection mechanisms detected by
    the DNA working group, and corresponding IPv4 mechanisms, such as
    [draft-ietf-dhc-dna-ipv4].

2.  Locally Operational Addresses

    Definition.  Locally Operational Address.  An available address is
    said to be locally operational when its use is known to be possible
    locally: the interface is up and the relevant default router (if
    applicable) is known to be reachable.

    Locally operational addresses are discovered and monitored through
    mechanisms outside MOBIKE.  These mechanisms include IPv6 Neighbor
    Discovery [RFC 2461], corresponding IPv4 mechanisms, and link layer
    specific mechanisms.

3.  Operational Address Pairs

    The existence of locally operational addresses are not, however, a
    guarantee that communications can be established with the peer.  A
    failure in the routing infrastructure can prevent the sending of
    packets. For this reason we need the definition of a second level
    of granularity, for pairs addresses:

    Definition.  Bidirectionally operational address pair.  A pair of
    locally operational addresses are said to be an operational address
    pair, iff bidirectional connectivity can be shown between the
    addresses.  That is, a packet sent with one of the addresses in the
    source field and the other in the destination field reaches the
    destination, and vice versa.

    Unfortunately, there are scenarios where bidirectionally operational
    address pairs do not exist.  For instance, ingress filtering or
    network failures may result in one address pair being operational in
    one direction while another one is operational from the other
    direction.  The following definition captures this general situation:

    Definition.  Undirectionally operational address pair.  A pair of
    locally operational addresses are said to be an unidirectionally
    operational address pair, iff packets sent with the first address as
    the source and the second address as the destination can be shown to
    reach the destination.

    Both types of operational pairs are discovered and monitored through
    the following mechanisms:

    o  Positive feedback from upper layer protocols.  For instance, TCP
       can indicate to the IP layer that it is making progress.  This is
       similar to how IPv6 Neighbor Unreachability Detection can in some
       cases be avoided when upper layers provide information about
       bidirectional connectivity [RFC 2461].  In the case of unidirectional
       connectivity, the upper layer protocol responses come back using
       another address pair, but show that the messages sent using the
       first address pair have been received.

    o  Explicit reachability tests.  For instance, the IKEv2 keepalive
       mechanism can be used to test that the current pair of addresses
       is operational.

    o  ICMP error messages.  Given the ease of spoofing ICMP messages,
       one should be careful to not trust these blindly, however.  One
       suggestion is to use ICMP error messages only as a hint to perform
       an explicit reachability test, but not as a reason to disrupt
       ongoing communications without other indications of problems.

4.  Primary Address Pair

    Contrary to SCTP which has a specific congestion avoidance design
    suitable for multi-homing, IP-layer solutions need to avoid sending
    packets concurrently over multiple paths; TCP behaves rather poorly
    in such circumstances.  For this reason it is necessary to choose a
    particular pair of addresses as the primary address pair which is
    used until problems occur, at least for the same session.

    A primary address pair need not be operational at all times.  If
    there is no traffic to send, we may not know if the primary address
    pair is operational.  Neverthless, it makes sense to assume that the
    address pair that worked in some time ago continues to work for new
    communications as well.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Oct 2004 23:31:59 +0200

=> you assume a peer address set management (OK).

=> some kind of loose pairing is needed if the knowledge
is a priori (OK but this can be a strong assumption).

=> OK

=> OK (usually the module tries to get this knowledge as soon
as possible but there is no general solution to provide this).

=> I disagree: the lower-layer here is the IP layer, and
it is the layer which can get the information. I don't
believe in IP connectivity without UDP connectivity even
this is possible in theory.

=> ask the MOBIKE module should be only an option.

=> this is why I said "should be only an option": the R-U-THERE
of IKEv2 is not well suited for parallel probing because of
the window issue. IMHO the real problem is that probes should
be at the IP layer not at the IKEv2 layer: one tries to probe
the IP paths, not the peer IKEv2.

=> another issue but IMHO the return routability checks and
NAT prevention stuff should be done before. Of course this is
true only in an ideal world.

=> we can use the fact the peer addresses are not part (if
one doesn't put them inside explicitely) of IKE messages,
i.e., the same request can be sent using different addresses
and each eventual reply has the addresses reversed.

=> IMHO the problem is about the "connectivity" term: it can be
either IP path availability or peer IKEv2 live check. The dead
peer detection is explicitely about the second case but what
we want here is the first one.

Thanks

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Oct 2004 00:07:39 +0200

=> IMHO the local choice should be done by a general module
and the role of the MOBIKE protocol is to inform the other peer.

   Details:
   
   1.  Available Addresses

=> it seems you are in favor of the "set" style.

       If a node loses the address it is currently using for communications,
       another address must replace this address.

=> in the "set" style this another address MAY be known before.

       And if a node loses an

=> IMHO this is one part (what I call "address management") of the
MOBIKE protocol.

=> more, it should wish the peer to accept it.

   

=> we can simply ask the address is usable for communication and
if we want to be strict we can ask the address is usable for IKEv2
communication (obviously when it is not the case we'll be in trouble).

=> I object: a link-local address should be available when the peer
is on the same link.

=> I strongly object: a private address must be available when
the peer is in the same RFC 1918 "realm".

       Available addresses are discovered and monitored through mechanisms
       outside the scope of MOBIKE.

=> so the previous discussion doesn't make sense.

       These mechanisms include IPv6
   
=> don't forget routing protocols when the node is a router (common
with SGs :-).

   
=> this is too strict: the peer can be on the same link so reachable
without a default router.

=> don't forget source address selection (RFC 3484).

   
=> you are trying to reinvent RFC 3484...

=> note this restricts MOBIKE to symmetrical connectivity.
IMHO this is a reasonnable constraint as IKEv2 requires it
(PS: does the constraint applies only to the IKE SA or
to both the IKE SA and the IPsec SA pairs?)

   
   
=> this is clearly outside the scope of MOBIKE IMHO!

=> is IPsec an upper layer protocol for this?

=> this is an application layer positive feedback when what it is needed
is at the network layer.

=> I propose to use exactly what it was specified for transport
protocols like TCP which share the issue.

   4.  Primary Address Pair

=> there is a simpler reason: the IKE SA uses *one* address pair.

=> communications? Perhaps you mean IKEv2 messages because other meanings
can be outside the scope of MOBIKE.

Regards

PS: if you remove every item outside of the scope of MOBIKE, you get
something very close to my "peer address management", don't you?
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Oct 2004 17:18:10 -0700

>   only an IKEv2 message exchange can tell that.

totally disagree with this particular statement. assuming the IP
stack is the lower layer (with might include MIP6/MULTI6), why
would MOBIKE be able to figure out something the IP stack couldnt?

UDP is a transport protocol on top of IP, right?

or am I missing the whole thing?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Oct 2004 18:23:39 -0700

Hello Jari,

a nice writeup. thanks. one comment below.

>    [draft-ietf-dhc-dna-ipv4].

this doesnt take into account some addresses that satisfy the above
conditions, but are restricted by certain policies on the MN. for
example, in an earlier mail, I had explained a scenario where I didnt
want MOBIKE to use an address configured from a low bandwidth GPRS
link to download email through a VPN tunnel.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Oct 2004 19:44:03 -0700

----- > 4.  Primary Address Pair
>     used until problems occur, at least for the same session.

Actually, SCTP doesn't send packets over multiple paths either. It uses the
addresses only for failover, that is when it detects a failure, it switches
to another address.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Oct 2004 20:06:46 -0700

Francis,

> the IP paths, not the peer IKEv2.

So is IP reachability both necessary and sufficient for "IKE-reachability"?

            jak

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Oct 2004 07:04:52 +0300

> link to download email through a VPN tunnel.

Right. Yes, I forgot that. Policy indeed needs to be taken
into account. Thanks for spotting this.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Oct 2004 07:07:03 +0300

> addresses only for failover, that is when it detects a failure, it switches

Yes, I think you are right about the usage of just one path at a
time. Question: does SCTP still have
some specific congestion avoidance for multi-homing, such as
going back to slow start upon changing to a different path?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Oct 2004 07:28:11 +0300

> UDP is a transport protocol on top of IP, right?

There appears to be several questions here. What Pasi is stating
need to made more specific before we can find agreement.
I think we are talking about:

(1) Difference wrt IP layer connectivity and the ability to
     talk between the IKEv2 peers.

     There is indeed a difference, the IKEv2 module could
     suddenly die... or the client could have been disconnected
     and the address recycled to someone else.

     Personally, I'm not sure this is worth covering. IP
     connectivity should be enough. But see (2) below.

(2) Ensuring that a given address really is the same
     node. When probing for the correctness of a claimed
     address, we may want to ensure that its indeed the
     same IKEv2 node at this address.

     It seems that the only way to do this is an IKEv2
     message. But note that we are talking about address
     update, not failure recovery here. So failure recovery
     might still work using only IP layer connectivity
     tests.

(3) What current lower layers are able to tell to MOBIKE.
     This is what I have been saying, that as far as I know,
     current lower layer support in IPv6, DNA, DHC, etc.
     only provides support for the discovery of available
     addresses and locally operational addresses. Not the
     discovery operational address pairs.

     I'm not saying that it wouldn't be possible to develop
     one, just that one doesn't exist now. But I could be
     missing something, I'm sure you guys will tell me what...

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Oct 2004 11:28:43 +0300

> would MOBIKE be able to figure out something the IP stack couldnt?

Because MOBIKE is the only one that can really say if there is
connection that is good enough for him. For the IP point of view the
connection between two IP-addresses might work even when there is NAT
between, which eats all UDP port 500/4500 packets. For MOBIKE point of
view the connection is broken. 

> UDP is a transport protocol on top of IP, right?

yes. And TCP is over IP, and even when TCP works it does not give us
any indication that UDP will really work. Also even if UDP for port x
works, it does not say anything whether UDP on port y will work. This
is because of firewalls, nats and similar things. Also sending one
ICMP message might make IP layer to think that the connection is
broken, and we propably do not want to allow that easy DoS attacks.

I think MOBIKE should get use and try to get as much information from
outside as possible, but in the end it still needs to test the
possible address pairs by itself to get positive feedback that the
address pair works.

The other layers can give lots all kind of hints, and most likely it
can give quite reliable negative feedback, i.e. it can say that this
address cannot work anymore as the interface used was removed from the
machine, or the DHCP server gave me new address etc. We can belive
some of that information but it might also give information saying
this IP-address is not working, as I got ICMP host unreachable back
to my ICMP ping message, and we propably should not belive that
information. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Oct 2004 10:57:03 -0700

> going back to slow start upon changing to a different path?

Depends on the amount of time the particular address pair is idle. This from
Section 7.2.1 of RFC 2960:

   Beginning data transmission into a network with unknown conditions or
   after a sufficiently long idle period requires SCTP to probe the
   network to determine the available capacity.  The slow start
   algorithm is used for this purpose at the beginning of a transfer, or
   after repairing loss detected by the retransmission timer.

   o  The initial cwnd before DATA transmission or after a sufficiently
      long idle period MUST be <= 2*MTU.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Oct 2004 11:05:59 -0700

>      might still work using only IP layer connectivity

I assume that could only be determined by authentication, so an IKEv2
message with proper ESP Auth header (or AH if that will be supported by
MOBIKE).

>      missing something, I'm sure you guys will tell me what...

Base reachability is determined by 2461 NUD (modulo the DNA work which is
still underway). I think RFC 2461 says that NUD can and should be
supplemented by upper layer reachability information. So from that
standpoint, MOBIKE could be considered an "upper layer" protocol that could
contribute to the NUD decision. The issue, as I see it,  is whether MOBIKE
should make the decision or not.

            jak

---

From: Greg Daley <[email-masked]>
Date: Thu, 14 Oct 2004 10:48:21 +1000

Hi Jari,

>     missing something, I'm sure you guys will tell me what...

It's possible that using DNA techniques, it may be possible to
tell when a path is not there for a subset of the cases
(based on local knowledge).

Mobile IPv6 is similar if there's knowledge that another trusted
address (for example a home address used in the IKE conversation)
is not available.  In this case, the knowledge about the
availability of the MIPv6 address is an extension of trust to
another location on the path. It looks like a local address to the
peer though, since it's used in end-to-end communication.

With non-local or non end-to-end information it's going to be difficult
to test unavailability unless there's preexisting or verifiable
trust from informants on the path. (for example if ICMPv6 destination
unreachable messages had authorization similar to that provided to
SEND (CGA) Routers).

If we can't trust indications from the network, we're stuck waiting
for IKE messages.

Greg

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 17 Oct 2004 22:03:56 -0700

I am not sure whether there is a consensus for this issue or not. But the
arguments are convincing (at least for me) that we need some IKEv2 message
to find the working pair of source and destination address. To make sure
i understand how this message is used, let me consider the following three
cases.

1) Mobility without multi-homing: In this case a single pair of address exists between
    the two nodes. When one of the node moves, MOBIKE detects at some point
    in time that there is a change at layer 3 e.g. using DNA/MIP6. MOBIKE
    learns about the new address using whatever mechanism the local OS provides,
    and sends an  address update to the other end. In this case, there is no need
    for any extra probing to look for a working pair.

2) Multi-homing without mobility : In this case there are multiple pair of addresses
    between the two nodes (Si, Dj). IKEv2 starts off with some address pair
    (S1, D1). At the end of successful IKE SA establishment, IKE knows the working
    pair of address which will be used for the further communication. MOBIKE kicks
    in at some point and each node updates the known local addresses with the other node.
    Whenever a new address is obtained e.g. a link to the ISP becomes UP, the other
     end is updated with this new address (it is really a matter of policy whether it is
     updated or not). Whenever an address ceases to work (hints from outside of MOBIKE),
     and that address is part of the current working pair, each end discovers this independently
     and starts to find a working pair. This is when you need a message at the IKEv2 level to
     find which address pair (Si, Dj) works. (I still don't understand the details of how both ends
     agree on a single pair of address. But that detail can be discussed later i guess) 

3) Multi-homing with mobility:  In this case there are multiple pair of addresses between
    the two nodes (Si, Dj) and one of the end is mobile. This case is not much different
    from (2). Mobility makes an address disappear or a new address appear. Whenever
   the node moves, an existing address becomes invalid. And if it is part of the existing working
   pair of address, MOBIKE can try and choose a new address by probing the other end
   (using the new IKEv2 message) or just update the other end with the new address just
   obtained (and only when that fails, start finding a different working pair).

Does this make sense ?

-mohan

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Oct 2004 17:08:35 -0700

sorry for the late reply.

I agree that while the IP stack (MIP6 or multi6) can determine
if there is a pair of addresses that the IP stack can use, we
still need an IKE message to figure out if the IKE endpoints
have a pair of addresses that they can use. and if the IP
stack (or a policy on the mobile node) tells MOBIKE to use a
particular address, that address should be tried first always.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 12:05:00 +0200

=> of course only necessary but what we need is not IKE reachability
but IPsec reachability.

PS: IMHO the IKE-reachability is already handled by IKEv2 itself, i.e.,
MOBIKE can add new failure cases but should not introduce its own new
mechanism.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 12:12:30 +0200

=> this is (check the address pair works) the job of the IPsec module,
not MOBIKE, at the exception of primary peer addresses for IKE messages.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 12:15:38 +0200

1) Mobility without multi-homing: In this case a single pair of address exists be
  tween
   
   2) Multi-homing without mobility : In this case there are multiple pair of addres
  ses
       between the two nodes (Si, Dj). IKEv2 starts off with some address pair
       (S1, D1). At the end of successful IKE SA establishment, IKE knows the workin
  g
       pair of address which will be used for the further communication. MOBIKE kick
  s
       in at some point and each node updates the known local addresses with the oth
  er node.
       Whenever a new address is obtained e.g. a link to the ISP becomes UP, the oth
  er
        end is updated with this new address (it is really a matter of policy whethe
  r it is
        updated or not). Whenever an address ceases to work (hints from outside of M
  OBIKE),
        and that address is part of the current working pair, each end discovers thi
  s independently
        and starts to find a working pair. This is when you need a message at the IK
  Ev2 level to
        find which address pair (Si, Dj) works. (I still don't understand the detail
  s of how both ends
        agree on a single pair of address. But that detail can be discussed later i 
  guess) 
   
   3) Multi-homing with mobility:  In this case there are multiple pair of addresses
   between
       the two nodes (Si, Dj) and one of the end is mobile. This case is not much di
  fferent
       from (2). Mobility makes an address disappear or a new address appear. Whenev
  er
      the node moves, an existing address becomes invalid. And if it is part of the 
  existing working
      pair of address, MOBIKE can try and choose a new address by probing the other 
  end
      (using the new IKEv2 message) or just update the other end with the new addres
  s just
      obtained (and only when that fails, start finding a different working pair).
   
   Does this make sense ?
   
=> none: MOBIKE is the tool to control, not the controling tool: if you remove
MOBIKE the mobile and/or multi-homed node should be still able to run without
the security.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 12:17:36 +0200

=> can you define "MOBIKE to use a particular address"?

Thanks

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 13:21:02 +0300

Hi Francis,

> not MOBIKE, at the exception of primary peer addresses for IKE messages.

Let me try to understand this statement better. Are you saying
that testing an address pair is the job of the ESP/AH module,
or that it belongs to the IKEv2 functionality already specified
(even without MOBIKE extension)?

I think you must mean the latter. Here's why: the current IKEv2
approach to this appears to be DPD, which works through IKEv2
messages, right? Or am I missing something?

(Certainly the lack of ESP packets might be a HINT that something
is wrong, but you wouldn't know if it was due to lack of need
to send packets until you try with DPD.)

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2004 12:26:45 +0200

=> we need both: IP connectivity and IKEv2 dead peer detection.
None is really a part of MOBIKE.

=> I agree: RR checks are the job of MOBIKE.

=> IMHO recovery should have the priority over RR checks. Note this
doesn't introduce a security issue because recovery is local and
will happen without RR checks in a non-IPsec context.

=> this is clearly the main job of a multi-homing control and
without it multi-homing is not really usable (*).

=> the question is more who should develop one.

Regards

PS (*): two remarks:
 - as there is currently no specified multi-homing control mechanism
   we are in trouble, with and without IPsec.
 - IMHO this is not the job of MOBIKE to provide this function, nor
   the job of the MOBIKE WG to specify one in place of the MULTI6 WG.
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 13:41:32 +0300

> => can you define "MOBIKE to use a particular address"?

I think that when Vijay said "MOBIKE" he meant the system
composed of IPsec, IKEv2, and MOBIKE. Essentially, its
the IKEv2 messages and IPsec AH/ESP packets that need to
use an address. There may be some MOBIKE control messages
too, but those are carried on top of IKEv2. And MOBIKE
exists for the reason that it should help IKEv2 and IPsec
traffic to go to the right address.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 13:46:45 +0300

Hi Francis,

> None is really a part of MOBIKE.

I think I agree with this too, now...

> => I agree: RR checks are the job of MOBIKE.

Ok.

> will happen without RR checks in a non-IPsec context.

The distinction between a probe to test whether an address
is usable for failover and whether its the same node in the
RR sense is a fine one. With proper protocol design, we
could actually achieve both in the same message. But I'm
also open to doing them separately. For instance, when I
tell you that I have address A, B, and C, you could verify
them at that time. Then when you get a problem with address
A, you could switch to B without any RR test. Nevertheless,
"switching to B" might imply a round of messages to B, so
this might not optimize very much.

> => the question is more who should develop one.

I agree.

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 28 Oct 2004 11:23:10 -0700

> => can you define "MOBIKE to use a particular address"?

I should have used better text. Jari clarified this.

Vijay