Subject: [Mobike] possibly related draft

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

Hi,

Francis' e-mail reminded me that I may need to point
also other folks to a possibly related draft.

One of the issues that we have been discussing is the
way how MOBIKE gets to know that it needs to use a new
address from a lower layer and how it can detect whether
a pair of addresses actually works or not.

This is not something that only we are looking at. SCTP
has specified its own way for this and HIP and MULTI6
protocols need solutions like that as well. As a member
of the MULTI6 design team I wrote some thoughts on the
matter from the point of view of MULTI6. If you take
a look it may give you some ideas for the MOBIKE space
too. I don't know about the solutions presented in the
draft, but I'm hoping that the draft might be helpful
at least in defining a few terms so that we can discuss
this matter more precisely.

Here's the draft:

   http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection-00.txt

--Jari

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Oct 2004 15:27:39 -0700

I am concerned about the use of some of this inferred information from 
the link layer or transport layer to decide connectivity at the network 
layer.

Notably, failure of TCP to make forward progress - e.g., lack of ACKs - 
is not an indication of a network layer connectivity failure. It can be 
a deliberate decision of the TCP implementation to limit processing 
associated with a connection, or can represent a security firewall being 
enabled.

Similarly, we've had related dicussions in TCPM regarding the use of 
ICMP unreachable messages to tickle more rapid attempts to use alternate 
addresses, e.g., for v4/v6 selection. Unfortunately, these messages, as 
noted, are not secure, and so relying on them presents a DOS 
opportunity; it is not clear that there is a significant benefit in 
'believing' these messages that is not undermined by this lack of security.

Although it may be useful to consider direct evidence of connectivity, 
e.g., linkup/linkdown interface notification via an API, it is not clear 
yet that there is a protocol-related variant that can be appropriately 
applied, IMO.

Joe

---

From: Greg Daley <[email-masked]>
Date: Fri, 29 Oct 2004 11:37:48 +1000

Hi Joe,

> yet that there is a protocol-related variant that can be appropriately 

At this stage there's no work done within DNA WG on APIs but we're
looking at getting indications of local connectivity from L2 into L3
within DNA WG.
Similar work has been going on with DNAv4 in DHC.

I'd guess that once the DNA system is able to indicate that an IP
configuration (addresses,local routers) is invalidated, or had
a connection discontinuity (e.g. link-layer only base station change)
This information could be passed to the upper layer protocols or IP
subsystems, in a similar fashion to a subset of the trigtran work
(but with only adjacent layer violations).

Hysteresis and security of the change discovery would probably exist
within the DNA subsystem, but information about trust could be
passed around too.  I'm not proposing this as a work item for DNA,
but it's intertesting for that group to see what people are really
interested in.

Please tell me if this is the right path to look down for local
connectivity indications (or not).

Greg D.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Oct 2004 07:06:45 +0300

Hi Joe,

> associated with a connection, or can represent a security firewall being 

Yes. Although -- given that we are talking about TCP that runs over our
IKEv2/IPsec connection -- the firewall will also block all other traffic
from the same connection, at least if non-null encryption and ESP are used.
I believe we have several types of connectivity:

- network layer connectivity
- IKE/IPsec connectivity
- transport or application connectivity

With ALGs and other kinds of interesting devices, you could
actually have a situation where you have application
connectivity but no network or IPsec connectivity. SImilarly,
network connectivity does not imply that IKE/IPsec gets
through.

> 'believing' these messages that is not undermined by this lack of security.

Right. The way that I want to see this is that anything like an
ICMP error would at best be a hint that now it would be a good
time to do another DPD round.

> yet that there is a protocol-related variant that can be appropriately 

Yes. Or at least the security/semantics impacts of the protocol
related variants need to be considered. I think this means that
we have three classes of notifications:

- Those that came through an API. However, most of the time the
   API-based indications are really initiated by (possibly insecure)
   protocol exchanges. For instance, the reception of an RA.
   In some cases there's security available (if in use) for these
   protocols, such as for ND we have SEND.

   However, I'd still feel uncomfortable if MOBIKE did NOT believe
   everything it hears from the API. We can't have a situation
   where ND decides something but the MOBIKE/IKEv2/IPsec system
   does not believe it and continues to use a bad address, for
   instance.

- Those that came through an external protocol, such as TCP.
   The considerations that you Joe raised apply here.

- Those that came through the MOBIKE/IKEv2/IPsec system itself.
   These I believe we *can* believe, and with some assumptions
   about the cryptographic primitives that are being used, this
   really represents the connectivity that MOBIKE is concerned
   about. Or does at least as long as one would test both IKEv2
   and ESP connectivity... in NAT-T case IKEv2 over UDP test
   would probably suffice.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Oct 2004 07:07:43 +0300

> connectivity indications (or not).

I think it is.

--Jari

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Oct 2004 21:55:29 -0700

Greg Daley wrote:
>> the link layer or transport layer to decide connectivity at the 
>> network layer.
>>
>> Notably, failure of TCP to make forward progress - e.g., lack of ACKs 
>> - is not an indication of a network layer connectivity failure. It can 
>> be a deliberate decision of the TCP implementation to limit processing 
>> associated with a connection, or can represent a security firewall 
>> being enabled.
>>
>> ICMP unreachable messages to tickle more rapid attempts to use 
>> alternate addresses, e.g., for v4/v6 selection. Unfortunately, these 
>> messages, as noted, are not secure, and so relying on them presents a 
>> DOS opportunity; it is not clear that there is a significant benefit 
>> in 'believing' these messages that is not undermined by this lack of 
>> security.
>>
>> e.g., linkup/linkdown interface notification via an API, it is not 
>> clear yet that there is a protocol-related variant that can be 
>> appropriately applied, IMO.
> 
> 

The similarity of this work to trigtran is what concerns me. If the 
information is direct and immediate - e.g., from an interface that loses 
signal to the OS (via an API), it seems reasonable. If the information 
is inferred from packet data or the loss thereof (inferred, rather than 
explicit), then there are substantial hazards, and it isn't clear that 
there is a feasible variant. This was the case with trigtran, as I recall.

> connectivity indications (or not).

I think it is, but there be dragons here.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Oct 2004 22:02:30 -0700

Jari Arkko wrote:
> connectivity but no network or IPsec connectivity.

Can you clarify this? it doesn't make sense to me. Sure, the network 
connectivity may be at multiple layers - the IP that carries the IPsec, 
the IP inside the IPsec (e.g., tunnel), etc., but I can't see how an 
application can connect in the absence of network connectivity.

> SImilarly,

Agreed.

> time to do another DPD round.

It's not yet clear that such hints should be acted on, or could trigger 
behavior that is unintended. The latter needs to be considered before 
assuming opportunistic reaction.

>   protocols, such as for ND we have SEND.

I was thinking more of non-protocol API signals, e.g., that a wireless 
card loses the carrier. I agree that protocol-based signals of link 
failure are worrisome - for many reasons, not just security.

>   does not believe it and continues to use a bad address, for

It makes more sense to create a system with keepalives that tears down 
the IKE or somesuch when they are not received, rather than to 'infer' 
anything based on hearing indirect information from an API. I.e., it is 
safe (IMO) to react to direct-connect API signals (carriers on cards on 
your box) or to signals you create for this purpose (e.g., keepalives 
inside an IKE association), but not to infer them from other protocols.

>   and ESP connectivity... in NAT-T case IKEv2 over UDP test

Presumably this would be akin to the keepalives noted above; if so, agreed.

---

From: Greg Daley <[email-masked]>
Date: Fri, 29 Oct 2004 16:05:31 +1000

Hi Joe,

Joe Touch wrote:
> 
> 
> Greg Daley wrote:
> 
>> Hi Joe,
>>
>> Joe Touch wrote:
>>
>>> I am concerned about the use of some of this inferred information 
>>> from the link layer or transport layer to decide connectivity at the 
>>> network layer.
>>>
>>> - is not an indication of a network layer connectivity failure. It 
>>> can be a deliberate decision of the TCP implementation to limit 
>>> processing associated with a connection, or can represent a security 
>>> firewall being enabled.
>>>
>>> Although it may be useful to consider direct evidence of 
>>> connectivity, e.g., linkup/linkdown interface notification via an 
>>> API, it is not clear yet that there is a protocol-related variant 
>>> that can be appropriately applied, IMO.
>>
>>
>>

DNA is only concerned with things it knows internally or verifiably
from (first hop) routing infrastructure which can be trusted,
or checked. I can understand the concerns though.

There were some ideas in trigtran which weren't explicitly known by
the host receiving the information: Out of band messages (ICMPv6),
remote indications in TCP...,

DNA's not really interested in event notifications except from its
own NIC (link up/link down).  It is able to infer configuration state
from neighbour/router discovery (using SEND, if available) messaging.

Once it knows about changes and events, it could provide
indications to the already mentioned services, but this is
still out of scope.

> I think it is, but there be dragons here.

I understand (or think I do).

We're really interested in making something work which

a) doesn't cause security headaches

b) doesn't get killed in IESG/IETF last call..

The API/upper layer indications stuff is currently out
of scope for DNA, but the change detection is there.
If you're interested, please have a look at some of the
work going on in DNA, because we'd certainly be
interested in feedback.

Greg

---

From: Jari Arkko <[email-masked]>
Date: Fri, 29 Oct 2004 10:55:26 +0300

Hi Joe,

> application can connect in the absence of network connectivity.

Anything that uses a proxy would be an example of a situation
where there's application layer connectivity but no lower layer
connectivity (to the peer). Anyway, maybe that is not so important
from the point of view of our discussion.

What's perhaps more important is that having network layer
connectivity does not imply IPsec/IKE gets through. And having
transport layer connectivity without IPsec/IKE at the bottom
does not imply that you would have IPsec/IKE connectivity.
Pretty much nothing else than IPsec/IKE can ensure that
there's IPsec/IKE connectivity...

> assuming opportunistic reaction.

I agree, but the way that I wanted to look at this is that
a hint leads to an activity that attempts to verify the hint
using a more secure mechanism (such as DPD). If this secure
mechanism reports that there is a problem, THEN we act, not
sooner. So the hint never directly leads to an actual change
in the IPsec/IKE addressing behavior.

> inside an IKE association), but not to infer them from other protocols.

I believe many people on this list have expressed the desire
to rely (at least partially) on other modules whose tasks
include things like verifying connectivity to the local router,
or change of on-link prefixes.

I take it that you feel uneasy with this. But let me point out
a few things:

(1) There's a difference between local information and
     global connectivity. I too would be hesitant to trust
     other protocols for the latter. But for the former
     I see little alternatives.

(2) Some of these other modules have security support. ND
     has SEND, for instance. And DHCP has some security
     tools too, although in many cases these tools aren't
     used.

(3) I can in a way understand your reluctance to use
     a particular insecure information piece from other
     modules. However, it seems that you MUST rely on
     it at least in some cases. For instance, when you
     boot your computer and get an IP address from the
     local network (possibly using an insecure version
     of ND or DHCP), there's really nothing that you
     could do in IPsec/IKE to avoid this. IPsec/IKE
     does not include the DHCP functionality.

     So it seems that you are stuck with the insecure
     modules/protocols at least for getting information
     about new addresses and connections. Presumably
     you could stick to these (despite advice from the
     other modules) until you have verified in the IPsec/IKE
     layer that they no longer work. But I think it
     doesn't help much, and could break other things.
     For instance, if ND says the link has changed and
     old addresses are gone, you should not continue to
     use your old address because it might collide with
     someone else's address on the new link.

> Presumably this would be akin to the keepalives noted above; if so, agreed.

Yes.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 29 Oct 2004 08:47:52 -0700

Joe,

>there is a feasible variant. This was the case with trigtran, as I recall.

My recollection is that Trigtran was derailed by the security issue. How can
I know that the ICMP message I've just received indicating a link is down
wasn't sent by an attacker wanting to DoS me?

Regarding inference from upper layers, RFC 2461 has this to say about using
upper layer information for NUD (Section 3):

   Neighbor Unreachability Detection detects the failure of a neighbor
   or the failure of the forward path to the neighbor.  Doing so
   requires positive confirmation that packets sent to a neighbor are
   actually reaching that neighbor and being processed properly by its
   IP layer.  Neighbor Unreachability Detection uses confirmation from
   two sources.  When possible, upper-layer protocols provide a positive
   confirmation that a connection is making "forward progress", that is,
   previously sent data is known to have been delivered correctly (e.g.,
   new acknowledgments were received recently).  When positive
   confirmation is not forthcoming through such "hints", a node sends
   unicast Neighbor Solicitation messages that solicit Neighbor
   Advertisements as reachability confirmation from the next hop.  To
   reduce unnecessary network traffic, probe messages are only sent to
   neighbors to which the node is actively sending packets.

This is meant to apply only to the local link (thus the phrasing of
"neighbor" which typically means a node on the local link), but since one of
those nodes is the last hop router, the implication here is that forward
progress  from upper layers can be used to infer whether the node's
connection off the local link is active, and thus whether IP needs to do
NUD.

This would indicate that, at least in IPv6, upper layers are expected to
participate in determining whether connectivity is available. I'm not sure
how that impacts MOBIKE, but I would expect lack of an upper layer positive
confirmation of "forward progress" might trigger MOBIKE to test for
activity, or select another SA if another address is available, in addition
to triggering NUD.

I don't think the statement in RFC 2461 explicitly contradicts your
assertion about what kind of information could be used by lower layers, but
it is suitably vague enough that it might be so construed. Perhaps the DNA
WG will help to clarify this in the end.

            jak

---

From: Greg Daley <[email-masked]>
Date: Mon, 01 Nov 2004 09:58:42 +1100

Hi James,

> WG will help to clarify this in the end.

We've tried to touch on this in draft-narayanan-dna-bcp-01.txt .
Sections 7.2 and 7.3 (both on page 17-18) are about processing
hints from other layers and timers.

The hints may or may not be used to initiate change and
reachability detection, based on hysteresis.  Section 7.5 on
hysteresis describes the threat of processing hints which
originate from protocol messages (page 19).

If there's need for more specificity regarding NCE state (considering
2461's vagueness) or concerns about the security of this approach
(for example, with mobike), please let us know.

Greg