Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt

From: Igor Lubashev <[email-masked]>
Date: Tue, 27 Nov 2012 17:10:28 -0800 (PST)

Mark, I've a few comments on this draft.

> 4.2. SLND Processing
> ...
>   4.  If the SLND Active Flag is off, the router
ignores the neighbor advertisement.

Unsolicited neighbor advertisements are integral for
new hosts to join the network or for failover configurations and should not be
disabled by routers by default.  By
default, routers should trust on-link hosts.  If there is a compromised host on the network, dropping unsolicited
neighbor advertisements from on-link hosts is of limited utility, if an
attacker who controls the host can mount an off-link sourced neighbor
solicitation attack to turn off the proposed on-link neighbor advertisement attack
defenses before launching the actual on-link neighbor advertisement
attack.  Moreover, an on-link attack can
be mitigated by administratively disabling the link access of the compromised
host, whereas mitigating an off-link attack is much more difficult.

> 4.2  SLND
Processing
> ...
> SLDN Activate Threshold.

If the router is implementing the defenses against
on-link neighbor advertisement attack, having a single "SLDN Activate
Threshold" can be harmful due to the possibility of hysteresis around the
threshold value, as pointed out by my co-worker, Deb Banerjee.  In that case, upon entering SLDN mode, the router would send a stateless
neighbor solicitation, only to drop the reply upon leaving SLDN mode.  A high/low watermark approach for "SLDN
Activate Threshold" is preferred in those cases.  In cases when a router will accept an
unsolicited neighbor advertisement, a single threshold is acceptable, though.

Also, when talking about the use of source address as a trust attribute, you may want to warn about the ease of spoofing such addresses.  I see the most value for source address as a trust attribute for non-public addresses (such as IETF reserved addresses)
that should not appear on the internet.  An IPv4-equivalents are RFC 1918 addresses like 10.0.0.0/8.  These packets are typically filtered out on
the border routers, so if packets with these source addresses are received, they originate
within the origination and could be afforded greater trust.

Best regards,

- Igor Lubashev

---

From: Mark Smith <[email-masked]>
Date: Wed, 28 Nov 2012 01:56:20 -0800 (PST)

Hi Igor,

Thanks very much to you and your colleagues for reviewing my draft.

>________________________________
> From: Igor Lubashev <[email-masked]>
>To: "[email-masked]" <[email-masked]> 
>Cc: Mark Smith <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Igor Lubashev <[email-masked]> 
>Sent: Wednesday, 28 November 2012 12:10 PM
>Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-05.txt
> 
>
new hosts to join the network or for failover configurations and should not be
disabled by routers by default.

In traditional stateful neighbor discovery, I don't think unsolicited (multicast) neighbor advertisements can create new entries in other nodes' neighbor caches, they can only update existing ones (7.6.2 in RFC4861). There is no text in that section about unsolicited unicast neighbor advertisements. Assuming unicast unsolicited neighbor advertisements aren't universally dropped, I'm sure they still would have to be updating an existing neighbor cache entry, rather than creating new ones.

That's one of the areas where stateless neighbor discovery would be different, there would be no existing neighbor cache entry to update, because it wasn't created at the time the node sent the neighor solicitation. When stateless neighbor discovery is active, all received unicast neighbor advertisements are accepted, and added to the neighbor cache if an entry doesn't already exist, regardless of whether they were triggered by a previous neighbor solicitation or not. That would be where stateless neighbor discovery is vulnerable to an on-link neighbor cache exhaustion DoS attack.

I'll try to make this a bit clearer in the next revision.

>  By

Agree, and that is the security trade off. Protecting against off-link sourced neighbor cache exhaustion DoS attacks is gained by sacrificing the state used (among other things) to prevent on-link sourced neighbor cache exhaustion DoS attacks. Given that on-link neighbors should be far more trustworthy than off-link ones, and that stateless neighbor discovery wouldn't require any changes to the ND NS and NA messages or other hosts' ND implementations, I think that this is a reasonable compromise.

Processing

I've thought in that case, the host that originated the traffic that triggered neighbor discovery's reliability mechanisms would take care of any loss of either the stateless neighbor solicitation towards the on-link target host, or loss off the neighbor advertisements in response (which may in include the drop you mentioned). As stateless neighbor discovery is really only intended to be used when there appears to be a neighbor cache DoS attack occurring, which should hopefully be a fairly rare event, so I'm generally trying to keep the mechanism simple, and to leverage existing reliability mechanisms to take care of gaps such as the one Deb identified.

>
>
>Also, when talking about the use of source address as a trust attribute, you may want to warn about the ease of spoofing such addresses.
>  I see the most value for source address as a trust attribute for non-public addresses (such as IETF reserved addresses)

Good point, a warning about trusting source addresses is sort of inherently in there (e.g. by only having the fc::/7 ULA prefix as the default trusted source prefix), however I'll put some text in about spoofing being a risk. 

I've been working on a new revision which I should have ready within a week or so. I'll incorporate you and your colleagues' comments. Thanks again for the review.

Best regards,
Mark.

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 28 Nov 2012 07:34:49 -0800 (PST)

Thank you for your comments, Mark!

>>> 4.2. SLND Processing 
>>> ...
>>>   4.  If the SLND Active Flag is off, the router ignores the neighbor advertisement.
>>
>>

> (snip)

>I'll try to make this a bit clearer in the next revision.

Thank you.  I know of at least one ISP that, as a defense against off-link neighbor solicitation attack, has turned off neighbor solicitations on their router entirely but is accepting unsolicited neighbor advertisements (at least on all-nodes multicast).  In any case, a clarification that a router MAY ignore neighbor advertisements _for addresses not already in the neighbor caches_ would be helpful.

>I've thought in that case, the host that originated the traffic that triggered neighbor discovery's reliability mechanisms would take care of any loss of either the stateless neighbor solicitation t…

An occasional single lost packet is certainly not a problem.  The concern here, however, is a possibility of a router entering a state with the neighbor table utilization right at the "SLDN Activate Threshold."  A single expiring neighbor table entry would take the router out of SLDN mode, while the next packet requiring a neighbor solicitation will activate SLDN mode right back.  Depending on the router's neighbor table expiration policy, it is conceivable that a number of neighbor table entries would expire one-by-one within a relatively short period of time.  If that happens, neighbor discovery could be impaired for that period of time.  This is admittedly not a likely possibility, and the timing would have to work out "just right".  If this is to be addressed, an alternative approach to high/low watermarks could be "SLDN Advertisement Delay" time parameter.  When "SLDN Activate Threshold" is no longer met, "SLND Active Flag" would be turned
 off as in the original proposal (and the router will create new neighbor table entries for sent solicitations).  However, the router would still accept all neighbor advertisements for "SLDN Advertisement Delay" time since turning off "SLND Active Flag".

Best,

- Igor