Hi Oliver, Thanks very much for your feedback.
----- Original Message ----- > From: Oliver <[email protected]> > To: [email protected] > Cc: > Sent: Tuesday, 16 October 2012 12:44 AM > Subject: Re: Fw: New Version Notification for > draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt > > On Friday 12 October 2012 17:57:52 Mark ZZZ Smith wrote: >> Hi, >> <snip> > > Hi, > > Overall I like the principle of the implementation but I would also say there > are a few issues that should be addressed: > > 1) TUSP should be defineable on an address/interface/packet marking basis; I > would say that the exact method of determining a trusted/untrusted querier > should (will) ultimately be down to the implementation and as such, this > should exist as a recommendation - perhaps call it a "TUD List" > instead > (Trusted/Untrusted Discriminator) with implementation of a TUD mandatory. > I think there is value in that (I think generalising is a good idea if you can do it), however I would be interested in some use cases where something other than the source address prefix would be a useful discriminator. I'm struggling to think of one right now. (It is 6.30 am which might explain it) > 2) While SLND is active, a packet that requires a solicitation MAY be dropped > outright but can optionally be requeued/buffered etc - queue discipline > should > be considered beyond the scope of this document. > I though about maintaining an "destination address independent" queue of traffic that triggered stateless neighbor discovery. I realised though I'd then have to work out answers to things like should new packets replace old ones, how big the queue is by default, and how it is worked out whether a packet can be removed from the queue. I then realised that there is probably already a queue of some form between the forwarding plane and the control plane of the router, so I though this new queue may not be worth the additional complexity it would create I'll review that decision though. One thing I'm also trying to do is keep in mind that this proposal is dealing with an exceptional case rather than a common case, meaning that the mechanisms might only be rarely if ever used. So I think there is some value in trying to keep the mechanisms as simple as possible. I'm still having a bit of a debate with myself as to whether the trusted/untrusted prefix mechanism is even necessary - to protect against the DoS it would be adequate to just resort to stateless ND for all traffic sources once the neighbor cache becomes reasonably near capacity. > I am also pondering the possibility of securing the on-link side by way of ND > cookies (with a prerequiste being that the subnet size is at least /64) > > Essentially, while using SLND, a node would generate a neighbour solicitation > for unknown on-link hosts using an algorithmically calculated source address > resulting from a hash operation over a node-unique seed, the target address > contained within the advertisement and the IPv6 header destination address. > > Thus when receiving a neighbor advertisement, the node can simply hash the > data in order to verify if the advertisement is spurious or not. The node > must > not bind to nor answer solicitatation for these calculated addresses. This > will ensure that in the event of a duplicate address, ND for the duplicate > would not result in a false discovery. > I like that idea because it doesn't require changes to hosts. However I'm not sure I understand how the neighbor advertisements would be sent back to the router issuing the neighbor solicitations? Where you think they would be multicast, so that the hash source address didn't have to be used to unicast them back to the router, avoiding the unicast ND related issues? > This does come with the downside that a solicited host will most likely > attempt discovery of the algorithmically calculated source address - however, > I would argue that the cost of this extra noise is outweighed by the benefit > of > ensuring non-spurious advertisements. > Thanks very much, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
