Subject: Creating a valid neighbour cache entry with an unsecured NS?

From: Greg Daley <[email-masked]>
Date: Thu, 15 Jul 2004 11:35:06 +1000

Hi

In conversation with Mohan and James,
I think I found an issue which is not sufficiently
covered in the base SEND draft.

Perhaps this is too late or not a major problem,
but here's a rundown:

Where SEND nodes provide backward compatability with
non-SEND nodes, it may be possible for a non-SEND attacker
to create a new neighbour cache entry on a victim SEND node
for a legitimate third party which also uses SEND.
In order for such an attack to occur, the SEND host
must have no SEND neighbour cache state for the third
node, and therefore has no existing data traffic.
The attacking node sends a solicitation message including
a Source Link-layer Address option to the
victim, purporting to be the third party.
This creates a neighbour cache entry in the STALE state,
which can be used for up to five seconds before
invoking neighbour unreachability detection.
While SEND messaging from the third party will override
is neighbour cache entry, upper layer confirmation
for the communication can be used to extend the lifetime
of the attack.

Here is some text to cover the issue:

(not sure about SHOULD NOT or MUST NOT for the second case.)

"
...

* Neighbor Solicitations for the purpose of Neighbor
   Unreachabilty Detection (NUD) MUST be sent to that
   neighbor's solicited-nodes multicast address, if the
   entry is not secured with SEND.

* Upper layer confirmations on unsecured neighbor cache entries
   SHOULD NOT update neighbor cache state from STALE to REACHABLE
   on a SEND node.  This ensures that if an entry spoofing a valid
   SEND host is created by a non-SEND attacker without being
   solicited, NUD will always be done within 5 seconds of use of
   the entry for data transmission.

..."

I think this would fit section 8 after the dot point:

* The Neighbor Cache, Prefix List and Default Router list
   entries MUST have a secured/insecure flag that indicates
   whether the message that caused the creation or last
   update of the entry was secured or insecure. Received
   insecure messages MUST NOT cause changes to existing
   secured entries in the Neighbor Cache, Prefix List or
   Default Router List. The Neighbor Cache SHOULD implement a
   flag on entries indicating whether the entry is secured.
   Received secured messages MUST cause an update of the
   matching entries and flagging of them as secured.

Greg

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Jul 2004 07:40:01 +0300

> invoking neighbour unreachability detection.

This is correct.

> for the communication can be used to extend the lifetime

This is true as well. I think the real question is if
we consider this as an attack, given that the third
party did not actually want to communicate with our
victim node. I guess the answer is "yes", because
the victim is still fooled into believing the third
party contacted it. For instance, my server could be
fooled into believing that my laptop contacted it
whereas in reality the laptop did not have a need
to contact the server and the communications actually
came from an attacker.

>   entry is not secured with SEND.

Ok.

>   the entry for data transmission.

This sounds OK too, although I do worry about the performance
impact to SEND nodes who are communicating with non-SEND
nodes. They'll be doing NUD all the time. Is this a problem?

--Jari

---

From: Greg Daley <[email-masked]>
Date: Thu, 15 Jul 2004 15:40:28 +1000

Hi Jari,

> nodes. They'll be doing NUD all the time. Is this a problem?

Perhaps it is too severe. Wireless devices may not like it...

If you have received a (real) solicited NA then you've got
bidirectional reachability with them, and no-one else
has responded.

maybe:

* Upper layer confirmations on unsecured neighbor cache entries
   SHOULD NOT update neighbor cache state from STALE to REACHABLE
   on a SEND node, if the neighbour cache entry has never previously
   been REACHABLE.  This ensures that if an entry spoofing a valid
   SEND host is created by a non-SEND attacker without being
   solicited, NUD will be done within 5 seconds of use of
   the entry for data transmission.

The words might sound a bit stilted, but this allows for
reachability testing.

Greg

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Jul 2004 13:39:27 +0300

> The words might sound a bit stilted, but this allows for

This would be OK. Lets make the change.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Jul 2004 10:01:52 -0700

> >   the entry for data transmission.

If I understand the suggested fix correctly, the receipt of an unsolicited
nonSEND NA for a unsecured cache entry would trigger an NS to probe whether
the host is at the expected destination. Naturally, the attacker could
answer back with an insecured NA, so there is no guarantee that the probe
will succeed in detecting the attack. If the host isn't using SEND, then
it's subject to ND-spoofing, so the suggested fix will only provide
protection if the attacker is attempting to disrupt traffic and not hijack
it.

So the suggested fix won't provide much protection. I'd suggest adding the
following sentence to the end of Greg's bullet:

       An attacker can naturally reply to the NUD probe with
       an insecure NA, so the protection provided by this measure
      only extends to detecting an attempt to disrupt traffic, not hijack
it.

Secured cache entries won't have this problem after they are established,
since an insecure NA for such will be discarded (Section 8, bullet 6). The
only real solution is to actually use SEND on the link. :-)

> nodes. They'll be doing NUD all the time. Is this a problem?

The problem will only occur if a nonSEND node sends an unsolicited NA to
report a link address change. Seems to me that such a link address change
typically doesn't happen very often, so the performance should not be a
large problem.

                  jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Jul 2004 10:03:19 -0700

Yes, this is a little better, but I still think the qualifier on the extent
of the protection should be added.

            jak

---

From: Greg Daley <[email-masked]>
Date: Fri, 16 Jul 2004 15:43:31 +1000

Hi James,

> protection if the attacker is attempting to disrupt traffic and not hijack

Actually, of the unsecured unsolicited NA case, no NC entry is created.

The issue is with the NS,RS or RA (with SLLAO), which all create
NC entries.

The purpose of the multicast NS for NUD on the unsecured NC entries,
is to ensure that the real owner of the address responds.
This will "trump" any unsecured NC state, and make the unsecured
NS,NA,RS,RA messages unable to affect the entry (which is now secured).

> only real solution is to actually use SEND on the link. :-)

   Hijacking an entry is halted by the responding NA to the
   NUD NS (which is multicast).  The initial hijack attempt
   will be unknown (and may not be preventable since we're accepting
   non-SEND packets) for up to 5 seconds while the NCE is in
   DELAY state before sending the NS.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Jul 2004 10:32:03 +0300

> So the suggested fix won't provide much protection. I'd suggest adding the

I think the purpose is to get the real node to respond, which would
overried the bogus entry.

Of course, the assumption is that the real node *is* on the link
and has not lost messages.

> following sentence to the end of Greg's bullet:

I'll suggest a slightly different additional sentence to the
Greg second bullet:

   As a result, in mixed mode attackers can take over
   a Neighbor Cache entry of a SEND node for a longer time
   only if (a) the SEND node was not communicating with the victim
   node so that there is no secure entry for it and (b) the
   SEND node is not currently on the link (or is unable to
   respond).

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Fri, 16 Jul 2004 08:39:32 -0700

OK, I missed the part about the multicast NS.

I withdraw the previously proposed text, and agree to Greg's additions as
posted.

            jak

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>;
<[email-masked]>
Sent: Thursday, July 15, 2004 10:43 PM
Subject: Re: Creating a valid neighbour cache entry with an unsecured NS?

---

From: "James Kempf" <[email-masked]>
Date: Fri, 16 Jul 2004 08:41:52 -0700

Yes, that sounds even better.

            jak

---

From: Greg Daley <[email-masked]>
Date: Mon, 19 Jul 2004 10:09:39 +1000

Hi Jari,

Jari Arkko wrote:
[chop]
>   SEND node is not currently on the link (or is unable to

Thanks for that, it provides context which wasn't
necessarily well explained by me.

Greg