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

From: Ray Hunter <[email-masked]>
Date: Thu, 28 Mar 2013 16:59:14 +0100

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: "[email-masked]" <[email-masked]>
>> To: [email-masked]
>> 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
>>
>