Hi Ray, Very sorry not to get back to you sooner. Thank you very much for your further review and comments.
----- Original Message ----- > From: Ray Hunter <v6...@globis.net> > To: Mark Smith <markzzzsm...@yahoo.com.au> > Cc: "6...@ietf.org" <6...@ietf.org> > Sent: Friday, 29 March 2013 2:59 AM > Subject: Re: Fw: New Version Notification for > draft-smith-6man-mitigate-nd-cache-dos-slnd-06.txt > > 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. > I have incorporated methods to cope with receiving Neighbor Advertisments that are received after a switch from stateful to stateless mode (i.e. update an neighbor cache entry if it exists), or from stateless mode to stateful mode (have a count down timer to accept Neighbor Advertisements for a period after going to stateful mode, as the Neighbor Solicitation was sent without creating state in stateless mode.) Are there any other situations that have been missed, or improvements in this area that wouldn't require exploitable state? > 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). > Agree. This proposal could serve as a mitigation, along with the other methods and improvements mentioned in RFC6583, while a registration protocol is developed and deployed. I'll need to find some time to go through your editorial comments in the near future. Thanks again for your review and comments. Very much appreciated. Best regards, Mark. > 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 --------------------------------------------------------------------
