Subject: Re: [netlmm] comments on netlmm-threats-00

From: Christian Vogt <[email-masked]>
Date: Mon, 24 Jul 2006 10:33:22 +0200

> Here are a couple of comments on the threats doc.

Hi Pekka,

thanks for your comments.  Responses inline...

> There were some assumptions and even explicit text which hinted at a
> tunnel-based solution... not sure if that is appropriate

Yes, you are right.  The text is more general now and even looks at
different possibilities for data plane transport if the transport could
make a difference with respect to an attack.  E.g., cf. last paragraph
of section 2.1, or last paragraph of section 2.3.

> substantial
> -----------
> 
> 1) What I'd have liked to see a bit more discussion about is you'll still need
> to be able to perform efficient ingress filtering at ARs.  Traditionally,
> it has been possible to spoof intra-link (= ~subnet) communication.  We
> don't want to be able to allow that in the whole NetLMM subnet.

Yes, documented this as ticket #94.

> 2) I don't understand the big deal about privacy issues.  Most of 
> these issues are about IP privacy in general and have little to do 
> with NetLMM as such.  For example in section 6.1 there seems to be 
> some discussion about propagation of link-local messages to figure out 
> whether the target is on the same link.  Well-- you could get the same 
> information (depending on mechanisms used) by watching TTLs, looking 
> at the latency to your target, try to send a frame to target's MAC 
> address directly,etc.

Yes, right.  We removed the section on privacy issues because those
issues were not NETLMM-specific.

> 3) I was looking more material on that would answer the following 
> quick NetLMM security problem statement I coined up:
> 
> "NetLMM makes the subnets larger.  There are a lot of attack vectors 
> inside a single link and sometimes a single subnet, and many protocols 
> make implicit or explicit trust assumptions about these properties. 
> Evaluate the most important protocols and see if you can summarize the 
> typical security approaches. How does NetLMM make them worse, and what 
> needs to happen to mitigate these threats?"

Pekka, the objective of the Threats document is to describe potential
attacks in a protocol-independent way, solely on the basis of the
prospective NETLMM architecture.

If we were to analyze other protocols with respect to how they
specifically may interact with NETLMM, then the Threats document would
explode in size.

> semi-editorial
> --------------
> 
>     Another threat on the interface between access routers and the MAP is
>     DoS against network entities.  Here, an  attacker manages to obtain a
>     globally routable IP address of an access router, a MAP, or some
>     other network entity, and perpetrates a DoS attack against that IP
>     address.  In general, NETLMM-based mobility management is somewhat
>     more resistant to DoS attacks than host-based localized mobility
>     management because nodes within the domain need never obtain a
>     globally routable IP address of any entity within the NETLMM domain.
>     As a consequence, a compromised node cannot pass such an IP address
>     off to an attacker, limiting the ability of an attacker to extract
>     information on the topology of the NETLMM domain.  It is still
>     possible for an attacker to perform address scanning if access
>     routers and MAPs have globally routable IP addresses, or for a
>     compromise to happen in another way, but the much larger IPv6 address
>     space makes address scanning considerably more time consuming.
>     Network operators need to take these considerations into account, and
>     ensure that their internal network topologies are sparsely populated.
> 
> ==> this is IMHO completely irrelevant to NetLMM.  These techniques are
> available without NetLMM, and NetLMM does not make them any worse.  So, in
> the interest of sticking to the main point -- NetLMM threats -- I'd remove
> this completely.

James and I had a discussion on whether we remove this part.  We
eventually agreed that the section should stay, albeit revised, because
the impact of a DoS attack may be different in NETLMM:  The impact may
be higher due to en-/decapsulation if the IP destination address in the
flooding packets is used by some MN.  The impact may be lower if the IP
destination address is unused because the LMA can then discard the
flooding packets after the routing table lookup.

The threat is now described in section 2.4.  Note the final comment:

                                                           [...]  This
   threat is in principle the same as for denial of service on a regular
   IPv6 border router, but because either the routing table lookup
   enables the LMA to drop a flooding packet early or, on the contrary,
   additional tunneling workload is required, the impact of an attack
   against localized mobility management may be different.

>    For packets to be later recognized as coming from the
>     mobile node, the mobile node's identity is tied to its IP address, or
>     possibly to any other identifier which shows up in the packets (e.g.,
>     the link-layer address or an IPsec SPI), during the initial
>     authentication procedure.
> 
> ==> I'm not sure how useful an IPsec SPI is, as that may change frequently
> due to automatic IKE re-keying..

We actually removed any suggested solutions from the draft, including
this one.  The focus of the draft is to be limited on the problem space;
there should not be any suggestions on how a problem might be solved.

>     A possible mechanism for link-layer authentication is a combination
>     of IEEE 802.11i technology and a function in the access router that
>     verifies whether or not an inbound packet's IP source address is
>     bound to the link-layer encryption keys.  At the IP layer, IPsec AH
>     provides appropriate protection.  Note that IPsec ESP is not
>     sufficient as it does not cover a packet's IP header.
> 
> ==> I'm surprised that you didn't mention PANA and SEND, as these might be
> applicable here.

Right, but again, we removed any proposed solutions, this one included.

>     If an attacker can forge a victim's mobile-node identifier or
>     generate packets that appear to originate from the victim, the
>     attacker can siphon off packets meant for the victim and redirect
>     them to its own location.  The perpetrator can inspect these packets,
>     effectively waging an "off-path" eavesdropping attack.  However, it
>     is impossible for the attacker to forward the packets on to the
>     victim given that the attacker and the victim use the same IP
>     address.  The compromised communication session is therefore highly
>     likely to abort before the attack causes significant damage.
> 
> ==> I'm puzzled by the "However," statement.  Why couldn't the attacker
> obtain two IP addresses -- one which it hijacks, and one which it uses as a
> source to communicate with the owner of the IP address.  Or just spoof an
> address.

If the attacker on link A behaves as a victim mobile node, the network
will redirect to link A all packets destined to the mobile node's IP
address.

So if the attacker would try and forward the packets to the victim
mobile node---which, say, sits on link B---, the attacker would have to
send the packets to the mobile node's IP address which the attacker
itself uses, too.  Hence, by definition of the attack, the network would
deliver those packets to link A.

The attacker can, of course, forward the packets if the victim is on the
same link (i.e., within link-layer reachability).  But the attacker
can't do this if the victim is on a different link.

> Actually, this attack is described in the next paragraph.  I'd reword these
> so that you describe the triangular routing MITM attack first, as it's the
> more useful variant, and then maybe describe what you may be able to do with
> just one IP address.

Actually, section 3.3 of the new draft version does not mention the
triangular routing MITM attack any more.  Do you think we should move it
back in?

> ...
> 
> 
> But since packets are tunneled on the sub-
>     path between the MAP and the mobile node's current access router, the
>     acquired information may not be sufficient to actually locate the
>     mobile node.
> ...
> 
>     This threat can be eliminated by filtering tracing attempts at the
>     NETLMM domain gateways.
> 
> ==> well, if you can find NetLMM node's access router, that's already
> probably sufficiently good indication of where the host is!

Yes, that's true.

But this kind of attack is not NETLMM-specific, so we removed it for
draft version 02.

> ==> note that 'filtering tracing options' is by no means trivial, 
> because what you'll have to do is basically block any communication of 
> ARs to the outside world (no TTL exceeded messages; no fragmentation 
> needed messages; no other kind of ICMP messages either).  This might 
> break IP badly (e.g., if AR has a Path MTU problem due to tunneling).

Ok.

> 9.  Informative References
> 
> ==> some of these should probably be normative..

Yes, reference [1], "Problem Statement for Network-based Localized
Mobility Management", and reference [3], "Mobility Related Terminology",
should be normative.  Documented this as ticket #95:

http://www1.tools.ietf.org/wg/netlmm/trac/ticket/95

> 
> editorial
> ----------
> 
>    Rouge access routers and MAPs can be handled with the same security
> 
> ==> s/Rouge/Rogue/

Ok.  Will be corrected in version 03.

>     The attacker not necessarily needs to be a customer of the NETLMM
>     domain since it does not have to authenticate itself to the NETLMM
> 
> ==> s/not necessarily needs/doesn't necessarily need/

Thanks.

> 4.2  Off-Path Eavesdropping
> 
> ==> it might be worth clarifying that "off-path" probably refers to a
> different physical link, but the same IP subnet in the NetLMM domain -- not
> off-path in general.

Yes, thanks.  The new terminology is "off-link" if the attacker is on an
access link.  If the attacker is somewhere within the NETLMM
domain---e.g., when it impersonates an LMA or a MAG---, the terminology
is either "off data plane path" or "off control plane path" (as these
two may not necessarily have to be the same).

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

Pekka Savola wrote:
> Hi,
> 
> Here are a couple of comments on the threats doc.
> 
> There were some assumptions and even explicit text which hinted at a
> tunnel-based solution... not sure if that is appropriate
> 
> substantial
> -----------
> 
> 1) What I'd have liked to see a bit more discussion about is you'll still need
> to be able to perform efficient ingress filtering at ARs.  Traditionally,
> it has been possible to spoof intra-link (= ~subnet) communication.  We
> don't want to be able to allow that in the whole NetLMM subnet.
> 
> 2) I don't understand the big deal about privacy issues.  Most of these issues are about IP privacy in general and have little to do with NetLMM as such.  For example in section 6.1 there seems to be some discussion about propagation of link-local messages to figure out whether the target is on the same link.  Well-- you could get the same information (depending on mechanisms used) by watching TTLs, looking at the latency to your target, try to send a frame to target's MAC address directly,etc.
> 
> 3) I was looking more material on that would answer the following quick NetLMM security problem statement I coined up:
> 
> "NetLMM makes the subnets larger.  There are a lot of attack vectors inside a single link and sometimes a single subnet, and many protocols make implicit or explicit trust assumptions about these properties. Evaluate the most important protocols and see if you can summarize the typical security approaches. How does NetLMM make them worse, and what needs to happen to mitigate these threats?"
> 
> semi-editorial
> --------------
> 
>    Another threat on the interface between access routers and the MAP is
>    DoS against network entities.  Here, an  attacker manages to obtain a
>    globally routable IP address of an access router, a MAP, or some
>    other network entity, and perpetrates a DoS attack against that IP
>    address.  In general, NETLMM-based mobility management is somewhat
>    more resistant to DoS attacks than host-based localized mobility
>    management because nodes within the domain need never obtain a
>    globally routable IP address of any entity within the NETLMM domain.
>    As a consequence, a compromised node cannot pass such an IP address
>    off to an attacker, limiting the ability of an attacker to extract
>    information on the topology of the NETLMM domain.  It is still
>    possible for an attacker to perform address scanning if access
>    routers and MAPs have globally routable IP addresses, or for a
>    compromise to happen in another way, but the much larger IPv6 address
>    space makes address scanning considerably more time consuming.
>    Network operators need to take these considerations into account, and
>    ensure that their internal network topologies are sparsely populated.
> 
> ==> this is IMHO completely irrelevant to NetLMM.  These techniques are
> available without NetLMM, and NetLMM does not make them any worse.  So, in
> the interest of sticking to the main point -- NetLMM threats -- I'd remove
> this completely.
> 
>   For packets to be later recognized as coming from the
>    mobile node, the mobile node's identity is tied to its IP address, or
>    possibly to any other identifier which shows up in the packets (e.g.,
>    the link-layer address or an IPsec SPI), during the initial
>    authentication procedure.
> 
> ==> I'm not sure how useful an IPsec SPI is, as that may change frequently
> due to automatic IKE re-keying..
> 
>    A possible mechanism for link-layer authentication is a combination
>    of IEEE 802.11i technology and a function in the access router that
>    verifies whether or not an inbound packet's IP source address is
>    bound to the link-layer encryption keys.  At the IP layer, IPsec AH
>    provides appropriate protection.  Note that IPsec ESP is not
>    sufficient as it does not cover a packet's IP header.
> 
> ==> I'm surprised that you didn't mention PANA and SEND, as these might be
> applicable here.
> 
>    If an attacker can forge a victim's mobile-node identifier or
>    generate packets that appear to originate from the victim, the
>    attacker can siphon off packets meant for the victim and redirect
>    them to its own location.  The perpetrator can inspect these packets,
>    effectively waging an "off-path" eavesdropping attack.  However, it
>    is impossible for the attacker to forward the packets on to the
>    victim given that the attacker and the victim use the same IP
>    address.  The compromised communication session is therefore highly
>    likely to abort before the attack causes significant damage.
> 
> ==> I'm puzzled by the "However," statement.  Why couldn't the attacker
> obtain two IP addresses -- one which it hijacks, and one which it uses as a
> source to communicate with the owner of the IP address.  Or just spoof an
> address.
> 
> Actually, this attack is described in the next paragraph.  I'd reword these
> so that you describe the triangular routing MITM attack first, as it's the
> more useful variant, and then maybe describe what you may be able to do with
> just one IP address.
> 
> ...
> 
> 
> But since packets are tunneled on the sub-
>    path between the MAP and the mobile node's current access router, the
>    acquired information may not be sufficient to actually locate the
>    mobile node.
> ...
> 
>    This threat can be eliminated by filtering tracing attempts at the
>    NETLMM domain gateways.
> 
> ==> well, if you can find NetLMM node's access router, that's already
> probably sufficiently good indication of where the host is!
> 
> ==> note that 'filtering tracing options' is by no means trivial, because what you'll have to do is basically block any communication of ARs to the outside world (no TTL exceeded messages; no fragmentation needed messages; no other kind of ICMP messages either).  This might break IP badly (e.g., if AR has a Path MTU problem due to tunneling).
> 
> 9.  Informative References
> 
> ==> some of these should probably be normative..
> 
> editorial
> ----------
> 
>   Rouge access routers and MAPs can be handled with the same security
> 
> ==> s/Rouge/Rogue/
> 
>    The attacker not necessarily needs to be a customer of the NETLMM
>    domain since it does not have to authenticate itself to the NETLMM
> 
> ==> s/not necessarily needs/doesn't necessarily need/
> 
> 4.2  Off-Path Eavesdropping
> 
> ==> it might be worth clarifying that "off-path" probably refers to a
> different physical link, but the same IP subnet in the NetLMM domain -- not
> off-path in general.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm