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

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 12 Oct 2012 17:57:52 -0700 (PDT)

Hi,

Here's a new version of my stateless neighbor discovery draft. Changes:

- make it more obvious that hosts don't need to be changed
- more informative introduction/problem definition text
- allow low end/embedded platforms to consider all traffic sources untrusted if a DoS attack is occurring
- misc. text re-wordings and changes

Thanks to Ray Hunter and Matthew Moyle-Croft for their reviews and comments.

Comments most appreciated.

Thanks,
Mark.

----- Forwarded Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Saturday, 13 October 2012 11:49 AM
> Subject: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt
> 
> 
> A new version of I-D, draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt
> has been successfully submitted by Mark Smith and posted to the
> IETF repository.
> 
> Filename:     draft-smith-6man-mitigate-nd-cache-dos-slnd
> Revision:     01
> Title:         Mitigating IPv6 Router Neighbor Cache DoS Using Stateless 
> Neighbor Discovery
> Creation date:     2012-10-13
> WG ID:         Individual Submission
> Number of pages: 11
> URL:            
> http://www.ietf.org/internet-drafts/draft-smith-6man-mitigate-nd-cache-dos-slnd-01.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-01
> Diff:            
> http://www.ietf.org/rfcdiff?url2=draft-smith-6man-mitigate-nd-cache-dos-slnd-01
> 
> Abstract:
>    The IPv6 neighbor discovery cache is vulnerable to a Denial of
>    Service attack that purposely exhausts the state used during the
>    neighbor discovery address resolution process.  This attack can be
>    very disruptive when the target is a router.  This memo proposes a
>    stateless form of neighbor discovery to be used by routers to
>    mitigate this attack.  It does not require any changes to hosts.
> 
>                                                                                 
>   
> 
> 
> The IETF Secretariat
>

---

From: Karl Auer <[email-masked]>
Date: Sat, 13 Oct 2012 12:25:15 +1100

> Here's a new version of my stateless neighbor discovery draft. Changes:

This para seems a little harder to understand than it should be:

   "A default route should never be used to define a trusted
    packet source prefix.  If a router's operator wishes to
    trust all packet sources, they should specify ::/0 as a
    configured trusted prefix."

It seems to be saying "never use a default route to define a trusted
packet source prefix. If a router's operator wishes to trust all packet
sources, they should use a default route"!

Because there are no ND cache entries for a packet except at the last
router in its journey, there is no way to delegate the problem upstream.
It would be nice if, once a router had decided to start rate limiting NS
from a prefix, it could pass that info upstream to have the upstream
router rate limit it instead (or as well). I appreciate that your
mechanism is not designed to do this, but I thought I'd mention it.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

---

From: Oliver <[email-masked]>
Date: Mon, 15 Oct 2012 15:44:28 +0200

On Friday 12 October 2012 17:57:52 Mark ZZZ Smith wrote:
> - allow low end/embedded platforms to consider all traffic sources untrusted
> if a DoS attack is occurring - misc. text re-wordings and changes
> 

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.

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 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.

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.

Kind Regards,
Oliver

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Oct 2012 12:30:25 -0700 (PDT)

Hi Karl, 

Thanks very much for your feedback.

----- Original Message -----
> From: Karl Auer <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Saturday, 13 October 2012 12:25 PM
> Subject: Re: Fw: New Version Notification for draft-smith-6man-mitigate-nd-cache-dos-slnd-01.txt
> 

I can see how that could be misinterpreted, although ::/0 is really only

the default when it is used as routing information. I'll try to reword
this text to make it a bit clearer that ::/0 is intended to be an "all
IPv6 addresses" prefix added to the configured source prefix list if all
sources are to be trusted.

> mechanism is not designed to do this, but I thought I'd mention it.

I like the idea of that, although the hard part is how to avoid creating
per destination address, or per source address or source prefix state
to do it, in either the router that is the target of the DoS, or the
upstream router(s) (e.g. per-source address backhole routes). It seems
to me that any state that is created that is created to store or created
related to IPv6 addresses is where address related DoS opportunities are
created. I've though about this idea a little bit for the last few days,
and can't see how you wouldn't create further address related state that
could be DoS exploited in either the device that is the target of the DoS,
or the upstream device.

One perspective on my proposal might be that it is in effect pushing most

of the functions that ND performs that use state back onto hosts that
originate the traffic in the first place, which results in that state
being distributed across those hosts, rather than being concentrated on
the directly attached router.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Oct 2012 13:31:10 -0700 (PDT)

Hi Oliver,

----- Original Message -----
> From: Oliver <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Tuesday, 16 October 2012 12:44 AM
<snip>
> (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)

> 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.

> 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?

> ensuring non-spurious advertisements.

Thanks very much,
Mark.

---

From: Oliver <[email-masked]>
Date: Mon, 15 Oct 2012 22:58:25 +0200

> struggling to think of one right now. (It is 6.30 am which might explain it)

I'd say there will ostensibly be situations where you do not actually care 
about the addresses you need to trust (or may simply not know it in 
advance/change so often that it's an administrative nightmare) but *do* know 
that all traffic arriving from interface X is trustworthy, in that instance, 
being able to classify by ingress interface would be invaluable.

Taking it to the extreme, arbitrary packet marks/tags provide a means to 
classify based on practically anything. Additionally, I can think of existing 
IPv6 implementations where there is already infrastructure for matching based 
on interfaces or marks but providing an in-stack table of addresses would be 
cumbersome.

> > 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.
> 

This wouldn't necessarily require a separate queue; any dequeued packet that 
results in a solicitation being sent would then need to have a counter set on 
it to prevent it from triggering another solicitation if dequeued again and 
eventually get dropped - this would then also open up the option of generating 
an ICMPv6 error at expiry. Essentially, a change to the architecture of the 
queue is more along the lines of what is required as opposed to maintaining an 
entirely separate queue.

> the neighbor cache becomes reasonably near capacity.

I'm definitely all for occam's razor, but I believe that being flexible is also 
important. The opportunistic level of complexity should be covered in the RFC 
and then left down to the implementor, otherwise I'd anticipate a situation 
where future RFCs end up being written after complex implementations have 
already come into existence. In other words, "attempt to cover all the bases" 
- providing some means of mitigating ND flooding is most certainly a Good 
Thing, whether it be rudimentary or everything but the kitchen sink, I would 
aim to set an acceptable baseline (which IMO this document has certainly 
already achieved) and also give opportunity & suggestions for exemplary 
robustness.

> > 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.
> > 
> > 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.
> >
> > 
> 

When sending an ICMPv6 neighbour solicitation, if there is an applicable data-
link layer, the sending host can indicate the appropriate L2 address as an 
added option to the ICMPv6 message - this results in the solicited node 
sending the neighbor advertisement response to that indicated data-link layer 
address, maintaining the IPv6 layer address as destination - however, if the 
node is unknown, without this option included, the L2 response destination 
will be taken from the L2 source of the solicitation.

Were it the case that sending a neighbour advertisement depended on already 
knowing the L2 address of the querier, IPv6 would have a serious chicken & egg 
problem :)

Kind Regards,
Oliver