Subject: draft-kempf-ipng-netaccess-threats-00.txt

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Nov 2001 10:17:08 -0800

I submitted draft-kempf-ipng-netaccess-threats-00.txt last week on Tues.
but got email from odin.isi.edu on Wed. that the mail had been delayed,
so I am not sure whether it got in on time. The actual email from the
Internet Drafts saying it was received arrived on Thurs. I have not seen
an announcement of the draft yet.

In any event, I put the draft on my Geocities web site. Here is the URL:

http://www.geocities.com/kempf42/draft-kempf-ipng-netaccess-threats-00.t
xt

I still hope we can get some discussion prior to the meeting.

                jak

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Nov 2001 09:20:00 +0200 (EET)

> I still hope we can get some discussion prior to the meeting.

I believe this is a very important document.

As with IPv4 and ARP (e.g. gratuituous ARP), it may be that the most
issues cannot be solved, at least without resorting to IPSEC.  But that is
perhaps not necessary -- in my book, it's good to identify problems even
though no proper "solution" can be found.

Comment on 3.3    Neighbor Solicitation/Advertisement Spoofing 
--8<--
   An attacking node can cause packets for legitimate nodes, both hosts 
   and routers, to be sent to some other link-layer address.  This can 
   be done by either sending a Neighbor Solicitation with a different 
   source link-layer address option, or sending a Neighbor 
   Advertisement with a different target link-layer address option. 
   If the spoofed link-layer address is a valid one, as long as the 
   attacker responds to the unicast Neighbor Solicitation messages sent 
   as part of the Neighbor Unreachability Detection, packets will 
   continue to be redirected. This is a redirect attack. 
[...]
--8<--
Here, it could be elaborated that NS messages with different link-local 
source address should overwrite the cached one [RFC2461 7.2.3]; the 
mechanism on how this attack works may not be self-evident.

Comment on 3.5 Bogus On-Link Prefix:
--8<--
   An attacking node can send a Router Advertisement message specifying 
   that some prefix of arbitrary length is on-link. If a sending host 
   thinks the prefix is on-link, it will never send a packet for that 
   prefix to the router. Instead, the host will try to perform address 
   resolution by sending Neighbor Solicitations, but the Neighbor 
   Solicitations will not result in a response, denying service to the 
   attacked host. This is a DoS attack. 
    
   The attacker can use an arbitrary lifetime on the bogus prefix 
   advertisement. If the lifetime is infinity, the sending host will be 
   denied service until it loses the state in its prefix list e.g. by 
   rebooting, or the same prefix is advertised with a zero lifetime. 
   The attack could also be perpetrated selectively for packets 
   destined to a particular prefix by using 128 bit prefixes, i.e. full 
   addresses. 
    
   This threat involves Router Advertisement messages. 
--8<--

It appears to me this is more than DoS.  This could be extremely evil -- 
what prevents the attacker from listening to all on-link traffic and 
responding posivitely to Neighbour Solicitations?  That way, it could act 
as a man-in-the-middle attacker for all destinations..  Scary..

Possible additional threat:

 - attacker assigns the subnet-router anycast address to itself. With 
various methods (like 3.3) it could capture the traffic meant to the 
address to itself.  Depending whether the anycast address is used for e.g. 
selecting the exit router, or being contacted by outside parties wishing 
to talk to the router of the subnet.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 23 Nov 2001 10:53:45 +0100 (CET)

> though no proper "solution" can be found.

I think we have existence proof that IPsec pixie dust does't work
well in practise...
If somebody wants to build a network where anybody can walk up and connect
yet want to limit the damage one "visitor" can do to another, it seems
like assuming pre-configured IPsec SAs for the multicast addresses used
by Neighbor Discovery is a non-starter.

> mechanism on how this attack works may not be self-evident.

OK.

> as a man-in-the-middle attacker for all destinations..  Scary..

I agree that this combined with NA spoofing can be used as a redirect attack.
We should make that clear I think (but I'm a bit concerned about there being
lots of possible combinations to mention in general.)

> to talk to the router of the subnet.

For packets sent from the outside to the subnet anycast address
one router at the endge of the subnet will receive it thus it will not
be forwarded onto the link.

So this is only an issue for subnet anycast packets sent from nodes on the
link. Currently there is no protocol that does this I think but it makes
sense adding the threat.

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Nov 2001 13:49:30 +0200

>by Neighbor Discovery is a non-starter.

Yes. (It could be a non-starter even if the network wasn't
public.)

Also, in your draft you write:

>In addition, Neighbor Discovery and Address Autoconfiguration use a 
>few fixed multicast addresses plus a range of 4 billion "solicited 
>node" multicast addresses.  A naive application of pre-configured 
>SAs would require pre-configuring an unmanagable number of SAs on 
>each host and router just in case a given solicited node multicast 
>address is used. Preconfigured SAs are impractical for securing such 
>a large potential address range.  

FYI: An old I-D dealing with the problems of preconfiguring SAs for
IPv6 'infrastructure' messages can be found from the following URL.
It includes a discussion of the kinds of attacks the IPv6 ND
and other 'link' functionality has.

http://www.arkko.com/publications/draft-arkko-manual-icmpv6-sas-00.txt

Jari

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 24 Nov 2001 21:23:43 +0200

>>by Neighbor Discovery is a non-starter.

I completely argree.

You may also want to have a look at my Cambridge
Security Protocols Workshop 2001 paper.

Pekka Nikander, "Denial-of-Service, Address Ownership,
and Early Authentication in the IPv6 World,", presented
at Cambridge Security Protocols Workshop 2001,
April 25-27, 2001, Cambridge University. To be published
in the workshop proceedings at the LNCS series.

http://www.tml.hut.fi/~pnr/publications/cam2001.pdf

--Pekka

---

From: "James Kempf" <[email-masked]>
Date: Tue, 27 Nov 2001 12:27:33 -0800

Pekka/Jari,

Thanx for the additional threats and the references. I will fold them
into the document on the next revision.

>though no proper "solution" can be found.

I sincerely hope that we can find an acceptable solution. Right now, the
preferred solution seems to be to make the link look like a
point-to-point link as much as possible because the access control
problems associated with point to point links are well understood in
public access networks. It would be a shame to have to propogate this
forward, especially for wireless networks where multi-access links are
likely to become more common.

            jak