I have finally got around to giving this draft a proper review. rfc6583 is an important concern for me and my customers.
IMHO I think the changes that have been made for this version are major improvements, and that the draft now does a very good job of describing a practical trade-off of giving up a few features of ND in order to protect against an off-link attack, without having to change neighboring implementations. One remaining concern is whether the change-over from normal to attack mode (and back) might not cause problems. IMVHO The only other option I have seen so far of how this could be significantly improved, whilst still maintaining the advantages of SLAAC, would be to change ND to a registration-type protocol, such as adopting the model used by 6LoWPAN-ND-Optimization (rfc6775). best regards, RayH Editorial comments ================== Section 1. s/prevent this Neighbor Discovery DoS Attack./prevent this Neighbor Discovery DoS Attack when mounted from off-link./ You reference rfc3756, which is absolutely correct. But rfc6583 provides additional details and should therefore probably (also) be referenced. s/advantage of hosts'/advantage of the end hosts'/ This is really for mitigating off-link attacks so I suggest 'router' rather than 'node'? An onlink attack to overflow the state table of the neighbor presence information for known neighbors was already possible (via multicast) and will now also be possible by unicast during SLNDP, so that isn't any improvement. s/This method would be used when a node's neighbor presence discovery state capacity reaches a medium to high threshold of use, suggesting a Neighbor Discovery DoS Attack is occurring./This method would be used when a router's neighbor presence discovery state capacity reaches a medium to high threshold of use, suggesting a Neighbor Discovery DoS Attack is occurring./ s/NPD is a worthwhile compromise when a Neighbor Discovery DoS Attack/NPD is a worthwhile compromise when a Neighbor Discovery DoS Attack appears to be occurring from off-link/ s/By making the NPD process stateless, hosts and routers would be protected against a Neighbor Discovery DoS Attack launched from a host against itself/ I disagree with this statement. An attacker who is on-link or on-host can still overflow any state table that registers known neighbors with gratuitous unsolicited entries that are no longer protected from having first to have been solicited. The problem of too much state has been moved: it hasn't been solved. Was the intention to say /By making the NPD process stateful in RFC4861, hosts and routers are protected against a Neighbor Discovery DoS Attack launched from a host against itself, or launched against a local router or neighboring node/? s/not assured of success./not assured of success, especially when placed under high load./ Section 5.1 s/five variables are maintained:/ five notional variables are maintained for the purpose of defining the algortihm: <p>These variables do not have to be made visible to other nodes, and are implementation dependent./ s/It is expressed as a percentage/It is expressed as a percentage for the purposes of defining the algorithm/ s/It is a per-interface variable/It should be a per-interface variable/ Section 5.2 s/is forwarded out the link-layer interface to its destination./is forwarded out the link-layer interface to its destination, as defined in RFC4861./ s/traditional stateful NPD is performed for the packet's destination./traditional stateful NPD is performed for the packet's destination, as defined in RFC4861./ s/The packet is then discarded./The inbound packet that triggered SLNPD may then be discarded in order to preserve local storage, or it may be retained in a queue for later transmission when the SLNDP process successfully completes. The queue should preferably be limited and reserved for packets that triggered SLNDP./ Section 5.3.1 s//The determination of trust is made based on/The determination of trust could be made based on Section 5.3.1.1. s/The source address of the packet that has triggered the NPD process can be used to/The source address of the packet that has triggered the NPD process may be used to/ Section 5.3.1.1.1. Suggest removing the paragraph on ULA. We don't yet truly know how ULA will be used. Mark Smith wrote: > Hi, > > Here is a new version of my "Stateless ND" draft, although a significant > amount of it has changed. > > During an off-list discussion with Ray Hunter, I came realise that calling it > "Stateless ND" was too general, as it implied that all of the ND functions > were being made stateless. I realised that what I was actually describing was > making the discovery of the presence of neighbors (which I've called > "Neighbor Presence Discovery") stateless when a ND DoS Attack appeared to be > occurring. Consequently I needed to rewrite a fair bit of the text describing > the problem. > > The other changes are - > > o don't ignore Neighbor Advertisements that may be part of a > previous stateful neighbor discovery transaction > > o use a count down timer to allow outstanding SLNPD transactions to > complete > > o mention issues regarding trusting packet attributes > > My thanks to the reviewers. Further review welcome and appreciated. > > Regards, > Mark. > > > ----- Forwarded Message ----- >> From: "internet-dra...@ietf.org" <internet-dra...@ietf.org> >> To: markzzzsm...@yahoo.com.au >> Cc: >> Sent: Thursday, 21 February 2013 6:14 AM >> Subject: New Version Notification for >> draft-smith-6man-mitigate-nd-cache-dos-slnd-06.txt >> >> >> A new version of I-D, draft-smith-6man-mitigate-nd-cache-dos-slnd-06.txt >> has been successfully submitted by Mark Smith and posted to the >> IETF repository. >> >> Filename: draft-smith-6man-mitigate-nd-cache-dos-slnd >> Revision: 06 >> Title: Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless >> Neighbor Presence Discovery >> Creation date: 2013-02-20 >> Group: Individual Submission >> Number of pages: 14 >> URL: >> http://www.ietf.org/internet-drafts/draft-smith-6man-mitigate-nd-cache-dos-slnd-06.txt >> Status: >> http://datatracker.ietf.org/doc/draft-smith-6man-mitigate-nd-cache-dos-slnd >> Htmlized: >> http://tools.ietf.org/html/draft-smith-6man-mitigate-nd-cache-dos-slnd-06 >> Diff: >> http://www.ietf.org/rfcdiff?url2=aft-smith-6man-mitigate-nd-cache-dos-slnd-06 >> >> Abstract: >> One of the functions of IPv6 Neighbor Discovery is to discover >> whether a specified neighbor is present. During the neighbor >> presence discovery process state is created. A node's capacity for >> this state can be intentionally exhausted to perform a denial of >> service attack, known as the "Neighbor Discovery DoS Attack". This >> memo proposes a stateless form of neighbor presence discovery to >> prevent this Neighbor Discovery DoS Attack. >> >> >> >> >> >> >> The IETF Secretariat >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
