Subject: Questions from the Authors of draft-gashinsky-v6nd-enhance

From: Joel Jaeggli <[email-masked]>
Date: Sun, 7 Aug 2011 10:57:45 -0700

Greetings,

This is followup from our discussion in both v6ops and 6man. We got a lot of useful input, but I would like to ask the mailing list to see if we can solidify this into a course of action.

For reference:

ftp://ftp.ietf.org/internet-drafts/draft-gashinsky-v6nd-enhance-00.txt

http://tools.ietf.org/agenda/81/slides/6man-9.pdf

1. Is this document (draft-gashinsky-v6nd-enhance) worthwhile?

2. Is there critique of the two proposed 4861 changes?

	A. 7.3  NDP Protocol Gratuitous NA

		a. We believe the is the question is whether the technique would 
		be useful under duress, wether it is potentially dangerous,
		if the safeguards are adequate, etc.

	B. 7.4 ND cache priming and refresh

3. Should we separate the potential mitigations (section 6) and implementation advice (section 7.1 and 7.2) into a separate document.

	A. Assumption (validated in v6ops at ietf81) is that v6ops would be happy
	 to take the mitigation and implementation advice as an informational document

	B. Assumption 2 a draft updating 4861 would be a standards track document.

	C. Assumption 3, should harmonize with  draft-nordmark-6man-impatient-nud-00

4. Is there anyone who thinks that an update to 4861 to address dos exposure is unnecessary?

	A. Just publish the advice and be done with it?

Comments on some or all of these questions would help the authors decide where to go next.

Thanks
Joel

---

From: Mark Smith <[email-masked]>
Date: Mon, 8 Aug 2011 07:28:14 +0930

Hi Joel,

I've been and am in the middle of starting a new job and moving
inter-state over the last few weeks, so I haven't been able to spend as
much time on this as I'd have liked to, as I'm quite interested in this
issue being resolved. I haven't had a chance, and won't over the next
few weeks to thoroughly read the draft, hopefully below is useful.

I have been working on my own proposal to address this issue by
abandoning the state held during the NS/NA transaction, and relying on
the traffic originating hosts to retransmit their NS/NA triggering
traffic if the stateless NS/NA transaction fails.

On Sun, 7 Aug 2011 10:57:45 -0700

> 1. Is this document (draft-gashinsky-v6nd-enhance) worthwhile?

Yes

> 	B. 7.4 ND cache priming and refresh

Haven't had the chance to thoroughly understand them yet.

> 3. Should we separate the potential mitigations (section 6) and implementation advice (section 7.1 and 7.2) into a separate document.

Yes. 

> 4. Is there anyone who thinks that an update to 4861 to address dos exposure is unnecessary?

I think this issue is essential to address. The end-users of the
Internet, and the services/applications they use, usually reside on
LANs, and LANs are vulnerable to this attack. The /127 or similar
techniques aren't applicable to LANs or point-to-point links such as SP
residential subscriber PPP/PPPoE sessions. A general method to resolve
this issue for all links, regardless of their role in the network or
their type should be the goal.

> Comments on some or all of these questions would help the authors decide where to go next.

HTH,
Mark.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 7 Aug 2011 15:12:42 -0700

Thanks!

---

From: Philip Homburg <[email-masked]>
Date: Mon, 08 Aug 2011 11:43:50 +0200

In your letter dated Sun, 7 Aug 2011 10:57:45 -0700 you wrote:
>	B. Assumption 2 a draft updating 4861 would be a standards track =
>document.

I think it would be best to create a discussion document that describes the
various ways that RFC-4861 can be changed to deal with remote attacks on
router (and to some extent host) ND.

---

From: "George, Wesley" <[email-masked]>
Date: Thu, 18 Aug 2011 15:43:48 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel Jaeggli
Sent: Sunday, August 07, 2011 1:58 PM
To: [email-masked]
Subject: Questions from the Authors of draft-gashinsky-v6nd-enhance

WEG] Yes

            B. 7.4 ND cache priming and refresh
WEG] might be worth thinking about situations where DHCPv6 is in use and whether that can be leveraged to achieve something similar to this, i.e. watch the DHCPv6 messages go past and pre-populate the ND cache accordingly.

2.      Should we separate the potential mitigations (section 6) and implementation advice (section 7.1 and 7.2) into a separate document.

WEG] yes. I think that there's value in getting the explanation and short-term mitigation techniques out there sooner rather than later, and then if there is consensus that there is protocol work to be done to further mitigate the issue because the workarounds and tweaks discussed aren't enough on their own, the workarounds and discussion of the security issue aren't being delayed by that protocol work.

            C. Assumption 3, should harmonize with  draft-nordmark-6man-impatient-nud-0<http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-0>0
WEG] Agree with all 3 assumptions.
Also, a comment on 7.1 - I think that this is roughly the right priority for certain applications, but not necessarily for all cases. In networks where it is more common for devices to be coming and going frequently, it may not be as appropriate to deprioritize traffic to unknown addresses. It may be that in a lot of those applications, DHCPv6 will be preferable to SLAAC, so this may not be a huge issue, but worth considering in this section's recommendations, especially if 7.4 is now in a separate document.

Thanks
Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Fred Baker <[email-masked]>
Date: Thu, 18 Aug 2011 14:13:18 -0700

> WEG] might be worth thinking about situations where DHCPv6 is in use and whether that can be leveraged to achieve something similar to this, i.e. watch the DHCPv6 messages go past and pre-populate…

If they go through your device, that makes sense. http://tools.ietf.org/html/draft-ietf-savi-dhcp would be an example. Any LAN that has two routers has a problem, though, as only one of them is likely to be/see the unicast DHCP responses.

---

From: james woodyatt <[email-masked]>
Date: Thu, 18 Aug 2011 15:52:36 -0700

> 	B. 7.4 ND cache priming and refresh

In the 6MAN session at IETF 81, I got up at the microphone and muttered some dark things about network sleep proxies. I should expand on those comments here on the list.

p1. Section 7.3 in the current draft deploys normative language thusly:

>>                                     [...] If the link layer address in
>>    an unsolicited neighbor advertisement matches that of the existing ND
>>    cache entry, routers SHOULD retain the existing entry updating it's
>>    status with regards to LRU retention policy. [...]

When a network sleep proxy accepts a new host registration, it will send a neighbor advertisement with a new and different source link-layer address, so routers that do this shouldn't have any trouble in the presence of network sleep proxies.

The next paragraph is marginally more interesting for its network sleep proxy considerations:

>>    Hosts MAY be configured to send unsolicited Neighbor advertisement at
>>    a rate set at the discretion of the operators.  The rate SHOULD be
>>    appropriate to the sizing of ND cache parameters and the host count
>>    on the subnet.  An unsolicited NA rate parameter MUST NOT be enabled
>>    by default.  The unsolicted rate interval as interpreted by hosts
>>    must jitter the value for the interval between transmissions.  Hosts
>>    receiving a neighbor solicitation requests from a router following
>>    each of three subsequent gratuitous NA intervals MUST revert to RFC
>>    4861 behavior.

Network sleep proxies are a subtype of hosts.  One imagines that a network sleep proxy might be configured to send unsolicited Neighbor Advertisements messages on behalf of sleeping hosts, which may or may not be configured differently than their proxy.  Moreover, network sleep proxies may themselves go to sleep, and transfer their registrations to another proxy.  Different proxies may or may not be configured the same way.

All this makes me wonder just how a host SHOULD be configured with its unsolicited neighbor advertisement rate.  Do we imagine defining a Router Advertisement option?  That's my preferred solution, because it would be useful even in the case where both M=0 and O=0.  It is, after all, a network configuration parameter and not really a host configuration parameter.  If we choose a Router Advertisement option, then we have to think about how to merge the advertisements from multiple default routers.

p2. Section 7.4 in the current draft has this to say:

>>    A solution to this would be that any new host that joins the network
>>    would "announce" itself, and be added to the cache, therefore not
>>    requiring packets destined to it to go through the unknown NDP queue.
>>    This could be done by sending a ping packet to the all-routers
>>    multicast address, which would then trigger the router's own neighbor
>>    resolution process, which should be in a different queue then other
>>    packets.

These echo requests will also be sent by network sleep proxies when they accept new registrations from existing hosts (including other sleep proxies) when they enter a sleeping mode.  It's probably worth noting that it isn't a good idea for a sleep proxy to send the echo requests *before* sending the unsolicited neighbor advertisement with the new link-layer address.  However, if the router under attack correctly processes the unsolicited neighbor advertisement, then the echo request should prime the neighbor cache in the router with the link-layer address of the sleep proxy.

Routers serving networks comprising lots of sleeping hosts and one or more network sleep proxies will be receiving a lot of echo requests from a small number of link-layer addresses, i.e. the sleep proxies, as hosts enter and leave sleeping mode.  It seems like there should be an opportunity to optimize on that.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 18 Aug 2011 16:04:08 -0700

> Network sleep proxies are a subtype of hosts.  One imagines that a network sleep proxy might be configured to send unsolicited Neighbor Advertisements messages on behalf of sleeping hosts, which ma…

James,

How would such sleep proxies interact with SeND?

I think if we want to support a form of registration of hosts (whether 
they are sleeping or not) it might be simplest to adopt the Address 
Registration option in draft-ietf-6lowpan-nd for wider use than 6lowpans.

My 2 cents,

    Erik

---

From: james woodyatt <[email-masked]>
Date: Thu, 18 Aug 2011 16:49:15 -0700

> How would such sleep proxies interact with SeND?

Theoretically, not very securely.  This problem, if you ask me, is one of the major deficiencies in SEND.  It needs to be revised to support sleep proxies.  (It's not just network sleep proxies that have trouble with SEND.  So do host sleep proxies.)

What I mean by "theoretically" is that, at present, I am unaware of neither any sleep proxies that implement SEcure Neighbor Discovery [RFC 3971], nor any that employ a security protocol of any kind between the sleeping host and the sleep proxy to which it registers.  "Security is hard; let's go SHOPPING!"

In theory, assuming all hosts and their sleep proxies are using SEND (because non-SEND nodes are not admitted to the network, or at least they aren't trusted by any of the other nodes they find on the network), then sleep proxies will need to possess the RSA private keys for all the CGAs that their client hosts register with them, and when sleep proxies themselves go to sleep, they may need to transfer those credentials to the next sleep proxy in turn.

I suppose one might imagine improving SEND with express support for sleep proxies, but I'm guessing that the major users of SEND are people for whom the choice to trade energy efficiency for network security doesn't usually require very much thought.

---

From: james woodyatt <[email-masked]>
Date: Fri, 19 Aug 2011 11:58:04 -0700

On Aug 18, 2011, at 4:49 PM, james woodyatt wrote:
> 
> ...then sleep proxies will need to possess the RSA private keys for all the CGAs that their client hosts register with them...

Correction: I think SEND as it is currently constituted actually just breaks sleep proxies entirely.  A cryptographically generated address is one-way function of the link-local address, and I'm pretty sure that sleep proxies shouldn't be sending source link-layer address options in neighbor discovery packets that don't match their own source hardware address.

And besides, if they did that to make SEND work, you'd still be going against section 9.1, which says:

   Even on a secured link layer, SEND does not require that the
   addresses on the link layer and Neighbor Advertisements correspond.
   However, performing these checks is RECOMMENDED if the link layer
   technology permits.

Really, I think SEND is basically incompatible with sleep proxies, which is the main reason I'm not in a big hurry to recommend implementing it in Apple products.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 19 Aug 2011 15:40:49 -0400

> WEG] might be worth thinking about situations where DHCPv6 is in use and whether that can be leveraged to achieve something similar to this, i.e. watch the DHCPv6 messages go past and pre-populate…

Wow. 

I hadn't though of that, but seeing as a bunch of things already snoop / relay DHCP, this seems clever...

W

> WEG] yes. I think that there’s value in getting the explanation and short-term mitigation techniques out there sooner rather than later, and then if there is consensus that there is protocol work to be done to further mitigate the issue because the workarounds and tweaks discussed aren’t enough on their own, the workarounds and discussion of the security issue aren’t being delayed by that protocol work.
>  
> Also, a comment on 7.1 – I think that this is roughly the right priority for certain applications, but not necessarily for all cases. In networks where it is more common for devices to be coming and going frequently, it may not be as appropriate to deprioritize traffic to unknown addresses. It may be that in a lot of those applications, DHCPv6 will be preferable to SLAAC, so this may not be a huge issue, but worth considering in this section’s recommendations, especially if 7.4 is now in a separate document.
>  
> Thanks
> Wes George
>  
>  
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 24 Aug 2011 09:20:23 -0700

> If they go through your device, that makes sense. http://tools.ietf.org/html/draft-ietf-savi-dhcp would be an example. Any LAN that has two routers has a problem, though, as only one of them is lik…

Also I mostly thought about this in the reverse context, e.g. a large number of hosts keeping the router's address in their cache.

it is possible to that this scenario is in fact invalid, which would make the draft simpler.