Hi Igor, Thanks very much to you and your colleagues for reviewing my draft.
>________________________________ > From: Igor Lubashev <igorl...@yahoo.com> >To: "ipv6@ietf.org" <ipv6@ietf.org> >Cc: Mark Smith <markzzzsm...@yahoo.com.au>; "nyg...@akamai.com" ><nyg...@akamai.com>; "dbane...@akamai.com" <dbane...@akamai.com>; Igor >Lubashev <iluba...@akamai.com> >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 > > >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. 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 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. > > 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. > > >> 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. > > 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) 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. > 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. > > >Best regards, > > >- Igor Lubashev > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
