Subject: [v6ops] DNSv6 Proxy !

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 May 2013 13:07:30 +0000

I just realized that neither
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-01#section-
5.1

Nit:

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 May 2013 13:14:25 +0000

I just realized that neither RFC6204, nor the bis draft
(http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-01#section
-5.1) have added any specifics for what IPv6 address should the CPE router
use while executing the DNS proxy function (if enabled).

Should it use the IPv6 address assigned to its WAN interface (which is to
be used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the
address assigned to its LAN interface via DHCPv6 PD ?

I happen to have an affinity to using the latter. Perhaps, a discussion is
worth here.

(Please ignore the previous email, which was a premature send)

Cheers,
Rajiv

PS: Just noticed a nit in the section 5.1, btw:

//If the service provider specifies one
or more DNS resolvers in DHCP configuration options, the CE
router SHOULD forward all non-local DNS queries unchanged to
those servers.

//

s/server/resolver

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 21 May 2013 13:52:09 +0000

> Should it use the IPv6 address assigned to its WAN interface (which is to be
> used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or the

IMO, the default behavior of the CE router would be to use default address selection as described in RFC 6724. Since 6204bis (and RFC 6204) requires the CE router to be an IPv6 node per RFC 6434, RFC 6434 requires address selection per RFC 3484, and RFC 6724 obsoletes RFC 3484, I think this is covered.

Since the DNSv6 query is being sent out the WAN interface, I would expect the CE router to select an address from among those it considers appropriate for traffic that it originates and sends out over that WAN interface. I would hope that access providers would not be surprised by a CE router considering a globally scoped, preferred, and valid address assigned to its WAN interface as being appropriate for traffic that the CE router sends out over the WAN interface. The idea that a CE router is supposed to interpret such an address assigned to its WAN interface as being reserved for a special purpose (CPE management) strikes me as odd. If the access provider wants to assign a special management address to the WAN interface, it would probably be best to assign an address that would not end up being the CE router's first pick for other traffic, per RFC 6724 guidance.
Barbara

---

From: Jared Mauch <[email-masked]>
Date: Tue, 21 May 2013 09:53:12 -0400

> router SHOULD forward all non-local DNS queries unchanged to

One more nit here, a CPE device providing DNS proxy MUST NOT listen to the WAN interface by default.  This poses a risk for DNS amplification attacks.  Right now about 46% of the IPs listed in the OpenResolverProject are CPE devices that respond on the WAN interface.

- Jared

---

From: Owen DeLong <[email-masked]>
Date: Tue, 21 May 2013 07:24:34 -0700

> IMO, the default behavior of the CE router would be to use default address selection as described in RFC 6724. Since 6204bis (and RFC 6204) requires the CE router to be an IPv6 node per RFC 6434, R…

Technically true, but given the chain of RFCs you had to put together to make that point, restating it clearly here might not be such a bad thing, no?

> Since the DNSv6 query is being sent out the WAN interface, I would expect the CE router to select an address from among those it considers appropriate for traffic that it originates and sends out o…

This incorporates a number of (not necessarily correct) assumptions about how things happen in the real world.

It is not at all unlikely that a provider would, e.g. design their network with one subset of their allocation used for management of CPE devices while using another subset for assigning customer addresses for general customer use. My understanding of RFC 6724 is that if the CPE were assigned (e.g.)
	2001:db8:1234::2 as a management address and
	2001:db8:9876::/48 for subscriber usage with the WAN link getting
	2001:db8:9876::2 with default gateway 2001:db8:9876::1, then
It would be ambiguous as to which of 2001:db8:1234::2 or 2001:db8:9876::2 would be used to source traffic by default.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 May 2013 14:35:51 +0000

> address assigned to its LAN interface via DHCPv6 PD ?

This doesn't make a lot of sense to me.   Why wouldn't it always use a source address that's configured on the interface on which it is transmitting the packet?

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 May 2013 23:39:36 +0900

> address assigned to its LAN interface via DHCPv6 PD ?

If I were implementing one, I would do the following:

    [1]  reserve one /64 from the PD for internal use by the resolver

    [2]  the DNS proxy would maintain a small set of keys, rotating periodically

    [3]  when generating/forwarding a request, take an
HMAC(Key_current, "normalized query parameters")

    [4]  extract 64bits from a consistent portion of the HMAC, and use
that as the lower 64 if the upstream request

    [5]  when a response arrives, compute:

                (a) HMAC(Key_current, "normalized query parameters"), and
                (b) HMAC(Key_previous, "normalized query parameters")

          and verify that the destination address (that reaches the
dns proxy in the CPE) matches the reserved prefix in [1] plus the
consistently extracted 64bits from either [5a] or [5b].

You could even pull 16 more bits from the HMAC to use as the source
port of the query (and hence destination port of the reponse) and
validate that as well.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 21 May 2013 17:10:05 +0200

> One more nit here, a CPE device providing DNS proxy MUST NOT listen to the WAN interface by default.  This poses a risk for DNS amplification attacks.  Right now about 46% of the IPs listed in the…
Rather than simply not binding to the WAN interface, shouldn't any CPE
hosting a DNS server or any other process providing services intended
for use exclusively by local nodes really be checking the sanity of the
source address AND the interface on which the request packet is arriving
("inside" or "outside")?

I don't see any requirements text in Section 4.5 of
draft-ietf-v6ops-6204bis-12 that states whether a firewall is enabled by
default, so the inside address of the CPE might also be addressable and
reachable from off-site hosts. The text does say "ought to" and
"expected to" but that ain't a requirement.

regards,
RayH

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 21 May 2013 15:31:17 +0000

> > IMO, the default behavior of the CE router would be to use default address
> > selection as described in RFC 6724. Since 6204bis (and RFC 6204) requires the
> > CE router to be an IPv6 node per RFC 6434, RFC 6434 requires address
> > selection per RFC 3484, and RFC 6724 obsoletes RFC 3484, I think this is
> > covered.
> >
> 
> Technically true, but given the chain of RFCs you had to put together to make
> that point, restating it clearly here might not be such a bad thing, no?

There are many, many cases where restating the obvious could be done. But doing so would result in a very long and effectively unusable RFC. 
In the absence of requirements that suggest otherwise, address selection per RFC 6724 from among addresses available for the interface that will be used to send the packet is pretty obvious, in my book. I only provided the chain to show that it was indeed covered by existing requirements.
> 
> > Since the DNSv6 query is being sent out the WAN interface, I would expect
> > the CE router to select an address from among those it considers appropriate
> > for traffic that it originates and sends out over that WAN interface. I would
> > hope that access providers would not be surprised by a CE router considering
> > a globally scoped, preferred, and valid address assigned to its WAN interface
> > as being appropriate for traffic that the CE router sends out over the WAN
> > interface. The idea that a CE router is supposed to interpret such an address
> > assigned to its WAN interface as being reserved for a special purpose (CPE
> > management) strikes me as odd. If the access provider wants to assign a
> > special management address to the WAN interface, it would probably be
> > best to assign an address that would not end up being the CE router's first
> > pick for other traffic, per RFC 6724 guidance.

> It is not at all unlikely that a provider would, e.g. design their network with
> one subset of their allocation used for management of CPE devices while
> using another subset for assigning customer addresses for general customer
> use. My understanding of RFC 6724 is that if the CPE were assigned (e.g.)
> 	2001:db8:9876::2 with default gateway 2001:db8:9876::1, then It
> would be ambiguous as to which of 2001:db8:1234::2 or 2001:db8:9876::2
> would be used to source traffic by default.
> 
> Owen

>From the perspective of the access network, the dangerous assumption would be to think that a generic "RFC 6204" or "6204bis" CE router device (i.e., no affiliation with any access provider, not designed per eRouter requirements, BBF TR-124, HGI home gateway requirements, or any other such org's requirements), would treat a globally scoped, preferred, and valid IPv6 address assigned to its WAN interface as anything other than fair game for all traffic that the CE router originates and sends out that WAN interface. To think that such an IPv6 address could be provided to a generic CE router, and the CE router would treat it as some sort of special "for management purposes only" address is a really, really, bad assumption. IMO, my assumption that this is a bad assumption is very well-grounded in how things happen in the real world.

If an access provider wants to be sure of what a CE router will do with addresses that it is given, then that access provider had better have some way of making sure that CE router meets additional requirements specified external to IETF. If the provider you describe has some idea of what they're doing, they will have specified requirements for CPE they want to manage; requirements would include such details as protocol for management, how to set up a management interface, credentials for management, etc. If the access provider you describe above is assigning all those addresses to some generic RFC 6204 / 6204bis CE router, that can have no assumed knowledge of management interfaces or protocols, and the provider is expecting those addresses to be used for the purposes you describe... well, that's just too bad. IETF RFCs are not cures for stupidity.

An access provider who allows subscribers to use generic, unidentified "6204/6204bis" CE routers also cannot assume that DNS queries coming from that subscriber's link will originate from an address assigned to the CE router's WAN interface. If the access provider consciously allows for such routers, I don't see why the access provider would care whether DNS queries originate from an address of a delegated prefix or an address assigned to the CE router's WAN interface.
Barbara

---

From: Owen DeLong <[email-masked]>
Date: Tue, 21 May 2013 12:28:54 -0700

>    [1]  reserve one /64 from the PD for internal use by the resolver

The problem with this approach is that you are assuming that the provider always grants at least n+1 /64s in the PD where n is the number of subnets needed on the client side.

Given that some ISPs are so misguided as to dole out /60s (or even less), I don't think you can take that for granted.

> port of the query (and hence destination port of the reponse) and

What do you gain from all this extra complexity that you don't get from DNSSEC?

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 21 May 2013 12:37:52 -0700

> There are many, many cases where restating the obvious could be done. But doing so would result in a very long and effectively unusable RFC. 

True, but this isn't one of those cases.

This is a case where the required chain of RFCs to arrive at the "obvious" is non-obvious and where restatement of the non-obvious (ideally with appropriate referential footnotes to the original RFCs) is brief and helpful.

> In the absence of requirements that suggest otherwise, address selection per RFC 6724 from among addresses available for the interface that will be used to send the packet is pretty obvious, in my…

While I would agree with you, that statement doesn't actually address at least one aspect of the question.

>> would be used to source traffic by default.

[quote level error corrected on the next paragraph, I believe this came from Barbara Stark] but it was quoted at the level to suggest I said it.

> From the perspective of the access network, the dangerous assumption would be to think that a generic "RFC 6204" or "6204bis" CE router device (i.e., no affiliation with any access provider, not de…

In the case of a generic router, I'm inclined to agree with you. However, that doesn't mean that such will not happen.
In fact, the way this will most likely happen is an SP that mostly provides routers to customers and forgets that the
customer routers that they didn't provide may not behave in this particular way or even remember after a few years
that this behavior is peculiar.

> An access provider who allows subscribers to use generic, unidentified "6204/6204bis" CE routers also cannot assume that DNS queries coming from that subscriber's link will originate from an addres…

Allows is always an interesting term in this context.

Owen

---

From: Jared Mauch <[email-masked]>
Date: Tue, 21 May 2013 16:05:33 -0400

> source address AND the interface on which the request packet is arriving

If it's doing DNS PROXY, it should only listen to the address it's advertising to the hosts that it routes on behalf of, and not those that are part of a ::/0 default range.

> "expected to" but that ain't a requirement.

Perhaps that needs to be fixed.  I'm seeing about 14 million CPE devices (at least) that are open resolvers in the IPv4 universe.  I want to make sure we are setting and specifying appropriate defaults instead of listening on [*:53]

- Jared

---

From: [email-masked]
Date: Tue, 21 May 2013 22:15:18 +0200 (CEST)

> Perhaps that needs to be fixed.  I'm seeing about 14 million CPE devices (at least) that are open resolvers in the IPv4 universe.  I want to make sure we are setting and specifying appropriate defa…

Yes, this needs to be fixed. In the meantime, some of us are putting
such a requirement (both for IPv4 and IPv6) into our RFQs etc.

Steinar Haug, AS 2116

---

From: Ray Hunter <[email-masked]>
Date: Tue, 21 May 2013 22:19:16 +0200

> Jared Mauch <mailto:[email-masked]>
> 21 May 2013 22:05
The point is that your suggested mitigation measure is not enough on its
own. If I'm an attacker performing an amplification attack, I don't care
about receiving the responses. It's simple enough to inject UDP packets
with spoofed source addresses. Not everyone on every remote site has
effective uRPF or ingress filters deployed, so IMHO the service/CPE must
also perform this uRPF type function itself locally.
> Perhaps that needs to be fixed.  I'm seeing about 14 million CPE devices (at least) that are open resolvers in the IPv4 universe.  I want to make sure we are setting and specifying appropriate defa…
Agree entirely with the goal of closing down open resolvers, but
mandating a default blanket inbound firewall is a separate discussion IMHO.
Mandating that services intended for local use must perform uRPF-like
checks and only accept connections from local addresses would solve the
problem without having to mandate a firewall.

regards,
RayH

---

From: Mark Smith <[email-masked]>
Date: Tue, 21 May 2013 14:25:19 -0700 (PDT)

<snip>
>>  Perhaps that needs to be fixed.  I'm seeing about 14 million CPE 
> devices (at least) that are open resolvers in the IPv4 universe.  I want to make 
> sure we are setting and specifying appropriate defaults instead of listening on 
> [*:53]
>> 
>>  - Jared

+1

The CPE should definitely protect itself and the services it provides from abuse (i.e. the CPE is a host in this capacity, and is implementing host based firewalling). I think trying to protect downstream hosts or not is a different issue (when the CPE is performing routing functions).

Regards,
Mark.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 May 2013 21:28:56 +0000

Perhaps, we want to phrase it like this - By default, DNS Query should only be processed, if received on the LAN-side interfaces. In other words, DNS Query should be ignored, if received on the WAN interface.

This doesn't necessarily mean 'firewalling', but can be done via 'firewalling'.

Incidentily, I didn't realize (until Jared's email went out) that my CPE router was an open resolver, despite the firewall being enabled (on LAN and WAN interafces), and I had to explicitly put an ACL to drop any TCP/UDP port=53 packets coming on the WAN interface.

Cheers,
Rajiv

> -----Original Message-----
> From: Ray Hunter [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2013 4:19 PM
> To: Jared Mauch
> Cc: Rajiv Asati (rajiva); [email-masked]
> Subject: Re: [v6ops] DNSv6 Proxy !
> 
> >>>> //If the service provider specifies one or more DNS resolvers in
> >>>> DHCP configuration options, the CE router SHOULD forward all
> >>>> non-local DNS queries unchanged to those servers.
> >>>>
> >>>> //
> >>>>
> >>>> s/server/resolver
> >>> One more nit here, a CPE device providing DNS proxy MUST NOT listen
> to the WAN interface by default.  This poses a risk for DNS amplification
> attacks.  Right now about 46% of the IPs listed in the OpenResolverProject
> are CPE devices that respond on the WAN interface.
> >>>
> >>> - Jared
> >> Rather than simply not binding to the WAN interface, shouldn't any
> >> CPE hosting a DNS server or any other process providing services
> >> intended for use exclusively by local nodes really be checking the
> >> sanity of the source address AND the interface on which the request
> >> packet is arriving ("inside" or "outside")?
> >
> > If it's doing DNS PROXY, it should only listen to the address it's advertising
> to the hosts that it routes on behalf of, and not those that are part of a ::/0
> default range.
> own. If I'm an attacker performing an amplification attack, I don't care about
> receiving the responses. It's simple enough to inject UDP packets with
> spoofed source addresses. Not everyone on every remote site has effective
> uRPF or ingress filters deployed, so IMHO the service/CPE must also
> perform this uRPF type function itself locally.
> >> draft-ietf-v6ops-6204bis-12 that states whether a firewall is enabled
> >> by default, so the inside address of the CPE might also be
> >> addressable and reachable from off-site hosts. The text does say
> >> "ought to" and "expected to" but that ain't a requirement.
> >
> > devices (at least) that are open resolvers in the IPv4 universe.  I
> > want to make sure we are setting and specifying appropriate defaults
> > instead of listening on [*:53]
> >
> > - Jared
> Agree entirely with the goal of closing down open resolvers, but mandating
> a default blanket inbound firewall is a separate discussion IMHO.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 May 2013 21:36:04 +0000

Ted,

Good Q. The answer is - it is valid to have just LLA only on WAN interface or IP unnumbered WAN interface of the CPE router. 

Also, it is possible that a broadband network design may have the GUA assigned on the WAN interface is not part of the subscriber/BNG session.  But this is a corner case.

Cheers,
Rajiv

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2013 10:36 AM
> To: Rajiv Asati (rajiva)
> Cc: [email-masked]
> > Should it use the IPv6 address assigned to its WAN interface (which is
> > to be used for CPE management, really) via DHCPv6 IA_NA or SLAAC, or
> > the address assigned to its LAN interface via DHCPv6 PD ?
> 
> This doesn't make a lot of sense to me.   Why wouldn't it always use a source
> address that's configured on the interface on which it is transmitting the
> packet?

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 May 2013 21:59:17 +0000

First, it is important to specify the DNSv6 behavior in the rfc6204bis draft. 

Second, 

> >>> IMO, the default behavior of the CE router would be to use default
> >>> address selection as described in RFC 6724. Since 6204bis (and RFC
> >>> 6204) requires the CE router to be an IPv6 node per RFC 6434, RFC
> >>> 6434 requires address selection per RFC 3484, and RFC 6724 obsoletes
> >>> RFC 3484, I think this is covered.

I don't think it is. 

Neither RFC6204 nor 6204bis include RFC 6434 as a normative or informative reference. 
Moreover, RFC6724 wouldn't provide a deterministic behavior to select one or the other address in case of DNS proxy. Additionally, it gets murky since the CPE WAN IPv6 address may or may not be part of BNG session. 

> >> It is not at all unlikely that a provider would, e.g. design their
> >> network with one subset of their allocation used for management of
> >> CPE devices while using another subset for assigning customer
> >> addresses for general customer use. My understanding of RFC 6724 is that
> if the CPE were assigned (e.g.)
> >> would be ambiguous as to which of 2001:db8:1234::2 or
> >> 2001:db8:9876::2 would be used to source traffic by default.

I agree with Owen. IMO, specifying the DNS proxy to use an address (it may well be the CPE router address on the LAN interface) from the DHCP-PD block would provide a deterministic behavior. And DNS messages would certainly get accounted for in the BNG subscriber session (as it should be)..  

Cheers,
Rajiv

> From: Owen DeLong [mailto:[email-masked]]
> Sent: Tuesday, May 21, 2013 3:38 PM
> To: STARK, BARBARA H
> >>> IMO, the default behavior of the CE router would be to use default
> >>> address selection as described in RFC 6724. Since 6204bis (and RFC
> >>> 6204) requires the CE router to be an IPv6 node per RFC 6434, RFC
> >>> 6434 requires address selection per RFC 3484, and RFC 6724 obsoletes
> >>> RFC 3484, I think this is covered.
> >>>
> >>
> >> Technically true, but given the chain of RFCs you had to put together
> >> to make that point, restating it clearly here might not be such a bad thing,
> no?
> >
> > There are many, many cases where restating the obvious could be done.
> But doing so would result in a very long and effectively unusable RFC.
> 
> This is a case where the required chain of RFCs to arrive at the "obvious" is
> non-obvious and where restatement of the non-obvious (ideally with
> appropriate referential footnotes to the original RFCs) is brief and helpful.
> 
> > In the absence of requirements that suggest otherwise, address selection
> per RFC 6724 from among addresses available for the interface that will be
> used to send the packet is pretty obvious, in my book. I only provided the
> chain to show that it was indeed covered by existing requirements.
> 
> >>> Since the DNSv6 query is being sent out the WAN interface, I would
> >>> expect the CE router to select an address from among those it
> >>> considers appropriate for traffic that it originates and sends out
> >>> over that WAN interface. I would hope that access providers would
> >>> not be surprised by a CE router considering a globally scoped,
> >>> preferred, and valid address assigned to its WAN interface as being
> >>> appropriate for traffic that the CE router sends out over the WAN
> >>> interface. The idea that a CE router is supposed to interpret such
> >>> an address assigned to its WAN interface as being reserved for a
> >>> special purpose (CPE
> >>> management) strikes me as odd. If the access provider wants to
> >>> assign a special management address to the WAN interface, it would
> >>> probably be best to assign an address that would not end up being
> >>> the CE router's first pick for other traffic, per RFC 6724 guidance.
> >
> >> This incorporates a number of (not necessarily correct) assumptions
> >> about how things happen in the real world.
> >>
> >> It is not at all unlikely that a provider would, e.g. design their
> >> network with one subset of their allocation used for management of
> >> CPE devices while using another subset for assigning customer
> >> addresses for general customer use. My understanding of RFC 6724 is that
> if the CPE were assigned (e.g.)
> >> would be ambiguous as to which of 2001:db8:1234::2 or
> >> 2001:db8:9876::2 would be used to source traffic by default.
> >>
> >> Owen
> >
> 
> [quote level error corrected on the next paragraph, I believe this came from
> Barbara Stark] but it was quoted at the level to suggest I said it.
> 
> > From the perspective of the access network, the dangerous assumption
> would be to think that a generic "RFC 6204" or "6204bis" CE router device
> (i.e., no affiliation with any access provider, not designed per eRouter
> requirements, BBF TR-124, HGI home gateway requirements, or any other
> such org's requirements), would treat a globally scoped, preferred, and
> valid IPv6 address assigned to its WAN interface as anything other than fair
> game for all traffic that the CE router originates and sends out that WAN
> interface. To think that such an IPv6 address could be provided to a generic
> CE router, and the CE router would treat it as some sort of special "for
> management purposes only" address is a really, really, bad assumption.
> IMO, my assumption that this is a bad assumption is very well-grounded in
> how things happen in the real world.
> 
> In fact, the way this will most likely happen is an SP that mostly provides
> routers to customers and forgets that the customer routers that they didn't
> provide may not behave in this particular way or even remember after a few
> years that this behavior is peculiar.
> 
> > If an access provider wants to be sure of what a CE router will do with
> addresses that it is given, then that access provider had better have some
> way of making sure that CE router meets additional requirements specified
> external to IETF. If the provider you describe has some idea of what they're
> doing, they will have specified requirements for CPE they want to manage;
> requirements would include such details as protocol for management, how
> to set up a management interface, credentials for management, etc. If the
> access provider you describe above is assigning all those addresses to some
> generic RFC 6204 / 6204bis CE router, that can have no assumed knowledge
> of management interfaces or protocols, and the provider is expecting those
> addresses to be used for the purposes you describe... well, that's just too
> bad. IETF RFCs are not cures for stupidity.
> >
> > An access provider who allows subscribers to use generic, unidentified
> "6204/6204bis" CE routers also cannot assume that DNS queries coming from
> that subscriber's link will originate from an address assigned to the CE
> router's WAN interface. If the access provider consciously allows for such
> routers, I don't see why the access provider would care whether DNS
> queries originate from an address of a delegated prefix or an address
> assigned to the CE router's WAN interface.
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 21 May 2013 22:11:34 +0000

I like Erik's proposal, since it would nicely plug the hole that Jared pointed out and also provide the source address to be used

> The problem with this approach is that you are assuming that the provider
> always grants at least n+1 /64s in the PD where n is the number of subnets
> needed on the client side.
> 
> Given that some ISPs are so misguided as to dole out /60s (or even less), I
> don't think you can take that for granted.

I don't see a non-trivial issue with applying Erik's proposal even if /64 was provided as DHCP-PD. After all, the CPE router must have to assign at least one IP address on its LAN interface. 

> What do you gain from all this extra complexity that you don't get from

I see DNSSEC being orthogonal since it is not about specifying which IP address to use as the source address, or whether or not to process the incoming DNS messages.

Cheers,
Rajiv

> Sent: Tuesday, May 21, 2013 3:29 PM
> To: Erik Kline
> >> Should it use the IPv6 address assigned to its WAN interface (which
> >> is to be used for CPE management, really) via DHCPv6 IA_NA or SLAAC,
> >> or the address assigned to its LAN interface via DHCPv6 PD ?
> >
> The problem with this approach is that you are assuming that the provider
> always grants at least n+1 /64s in the PD where n is the number of subnets
> needed on the client side.
> 
> Given that some ISPs are so misguided as to dole out /60s (or even less), I
> don't think you can take that for granted.
> 
> >          and verify that the destination address (that reaches the dns
> > proxy in the CPE) matches the reserved prefix in [1] plus the

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 May 2013 10:55:33 +1000

By default it offers recursion to local clients and returns REFUSED
to remote clients that it can't answer from local zone content.

If a CPE is proxying then it need to present as many address to the
internal clients as is proxing external nameservers.  It is long
past the time when a CPE can offer a single address for address
family.  DNS clients need to be able to actuately determine the
capabilities of the servers being proxied.  The applies to both
IPv4 and IPv6.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Wed, 22 May 2013 07:06:42 +0100

> capabilities of the servers being proxied.  The applies to both

If adding text for this, is it also worth nothing that future CPE's may act as authoritative name servers for domains used to refer to devices in the home? If so, the configuration advice wrt DNS amplification attacks is more likely to need to be similar to that of an enterprise.

Tim

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 22 May 2013 11:23:55 +0200

Well, I wouldn't be too sure about the presence of firewall on the CPE. 
At the last IPv6 congress in Paris (March 2013), one of the vendors on stage was promoting a more "open" approach, so no stateful firewall on it.

regs

Carl Wuyts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: dinsdag 21 mei 2013 23:25
To: Ray Hunter; Jared Mauch
Cc: [email-masked]
Subject: Re: [v6ops] DNSv6 Proxy !

<snip>
> checks and only accept connections from local addresses would solve 
> the problem without having to mandate a firewall.
> 

+1

Regards,
Mark.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 22 May 2013 11:27:01 +0200

Yes, it is valid to have LLA only on WAN interface, in fact, often used with e.g. PPP deployments.
Depending on what you'd like to do with WAN management, you might want to introduce unnumbered indeed, but as some (lots of in fact) customers still rely on IPv4 for management purposes, there's often no need to have IPv6 on WAN or unnumbered WAN.

Carl Wuyts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: dinsdag 21 mei 2013 23:36
To: Ted Lemon
Cc: [email-masked]
Subject: Re: [v6ops] DNSv6 Proxy !

Ted,

Cheers,
Rajiv

> address that's configured on the interface on which it is transmitting 
> the packet?

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 22 May 2013 11:28:38 +0200

Whatever is being decided here, take into account that all variants between /64 and /48 as ia_pd length exist in the real world.
And yes, I know, /64 is not ideal, but it is in place today so should not ignored.

Carl Wuyts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: woensdag 22 mei 2013 0:12
To: Owen DeLong; Erik Kline
Cc: [email-masked]
Subject: Re: [v6ops] DNSv6 Proxy !

> The problem with this approach is that you are assuming that the 
> provider always grants at least n+1 /64s in the PD where n is the 
> number of subnets needed on the client side.
> 
> Given that some ISPs are so misguided as to dole out /60s (or even 
> less), I don't think you can take that for granted.

Cheers,
Rajiv

> >> is to be used for CPE management, really) via DHCPv6 IA_NA or 
> >> SLAAC, or the address assigned to its LAN interface via DHCPv6 PD ?
> >
> The problem with this approach is that you are assuming that the 
> provider always grants at least n+1 /64s in the PD where n is the 
> number of subnets needed on the client side.
> 
> Given that some ISPs are so misguided as to dole out /60s (or even 
> less), I don't think you can take that for granted.
> 
> >    [4]  extract 64bits from a consistent portion of the HMAC, and 
> > use that as the lower 64 if the upstream request
> >

---

From: Owen DeLong <[email-masked]>
Date: Wed, 22 May 2013 11:58:09 -0400

> I like Erik's proposal, since it would nicely plug the hole that Jared pointed out and also provide the source address to be used

It goes well beyond the simplest and ideal solution to the stated problem…

> I don't see a non-trivial issue with applying Erik's proposal even if /64 was provided as DHCP-PD. After all, the CPE router must have to assign at least one IP address on its LAN interface. 

But it is frequently rotating that address and requires that the entire /64 be available for cryptographic hashing of the request in question. It makes no allowance for collision with an address in use for another host. As such, his proposal requires the dedication of an entire /64 that doesn't actually have any addresses devoted to other purposes.

> I see DNSSEC being orthogonal since it is not about specifying which IP address to use as the source address, or whether or not to process the incoming DNS messages.

But the whole point of his crypto-munging of the source address is to confirm that the reply is associated with an actual pending request and to make it difficult to guess the right address to send a forged reply to. Since DNSSEC eliminates the possibility of a forged reply, I don't see a benefit to all the introduced complexity.

Owen

---

From: Erik Kline <[email-masked]>
Date: Fri, 24 May 2013 11:15:13 +0900

> But it is frequently rotating that address and requires that the entire /64 be available for cryptographic hashing of the request in question. It makes no allowance for collision with an address in…

Well in my original thesis you wouldn't want to use a per-request IPv6
address unless you be sure you avoided the DAD penalty.  If a CPE had
only a single /64, or suspected that it could not allocated a /64 for
its own uses and have sufficient left-over space for customer use then
I would not recommend trying this scheme.

> But the whole point of his crypto-munging of the source address is to confirm that the reply is associated with an actual pending request and to make it difficult to guess the right address to send…

This statement seems kinda weird to me.  You seem to be saying that we
don't need source port randomization, or case randomization, or any
other mitigation technique against domain hijacking protection
("Kaminsky attack") because, hey, we have DNSSEC.  Either I've misread
you, or perhaps we really don't need such defensive tactics (I would
not claim to be a DNS expert)?

My proposal was just that we could add 64bits of more randomness to
the 16bits of the port and whatever bits of case-randomization, for
resolver self-defense.  To me, this is like wearing a seat belt and
having side impact cushions and daytime running lights.

Of course a resolver could do DNSSEC on behalf of its clients (even
when they don't do it themselves).  But something like <5% of queries
through Google Public DNS are for hostnames/records/zones that have
correctly validating DNSSEC set up.  Just saying "DNSSEC", to me is
like waiting for the rest of the world to learn how to drive safely.

(Apologies to Rajiv for distracting from his original point.)

---

From: Owen DeLong <[email-masked]>
Date: Thu, 23 May 2013 23:30:23 -0700

> I would not recommend trying this scheme.

Which makes it inappropriate for the draft under discussion which was my original point.

> not claim to be a DNS expert)?

If we implement DNSSEC, we don't need those tactics. Correct.

> having side impact cushions and daytime running lights.

DNSSEC is like a seatbelt and airbags. Port randomization is like adding
a helmet. Case randomization is akin to a fire suit.

Port randomization is a reasonable mitigation. Case randomization has
some level of diminishing returns, but it's mostly harmless. Especially
in an environment where DNSSEC is implemented. Port and Case
randomizations were primarily developed as stop-gaps to get by
while DNSSEC awaited broader deployment.

Your proposal would, in this particular situation, best be compared to
tearing the entire car apart to install a roll cage, active independent
suspension, and 5-point harnesses... Just to drive to a short distance
to work and back on low-speed lightly travelled streets.

In other words, it's way way way beyond the diminishing returns point
in my opinion.

> like waiting for the rest of the world to learn how to drive safely.

While there's truth in that, remember, we're talking in the context of
an ID that's purporting to be about requirements for residential CPE.

In that context, by the time anything in this ID gets deployed into actual
CPE, most likely, DNSSEC will be much more widely deployed.
DNSSEC is growing fairly rapidly.

However, even without it, your added 64 bits of randomness comes at
a cost which vastly exceeds its benefit IMHO.

Owen