Subject: [homenet] Mixing DNS in with routing information

From: RJ Atkinson <[email-masked]>
Date: Thu, 25 Oct 2012 12:08:15 -0400

On Thu, 25 Oct 2012 09:11:18 +0900, Lorenzo Colitti wrote, in part:
> ...from the border router which discovered the DNS entries
> for tvservice.jp, inject those DNS servers into the mesh
> with a tag that they only be used for tvservice.jp,
> and pass that around in the routing protocol. No?

I'm not comfortable with overloading a routing
protocol for use as a DNS transport mechanism.

I'm also nervous about both DNS authorisation
and DNS authentication.  Who is allowed to make 
which DNS advertisements and how do I authenticate 
the received DNS advertisement as both valid and 
authorised ?

  (NB: With ordinary DNS, the answer is DNSsec.  
   With mDNS, DNSsec also probably can work.)

Surely there is some alternative approach that
doesn't require such overloading and complexity.

Yours,

Ran

---

From: Sander Steffann <[email-masked]>
Date: Thu, 25 Oct 2012 19:32:30 +0200

Hi,

> the received DNS advertisement as both valid and 

Yes. The routing protocol saying 'please use this address to resolve google.com' might cause some problems... With DNSSEC in place it can still cause a denial of service when unsigned or invalidly signed data is returned.

Met vriendelijke groet,
Sander Steffann

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 09:33:37 +0900

> protocol for use as a DNS transport mechanism.

Sorry, I didn't mean "routing protocol". I meant "Homenet DNS Information
Distribution Protocol" (HIDP). I would expect a useful way to carry HIDP
would be using the homenet routing protocol which the homenet needs to
implement anyway, but other implementations such as global IPv6 multicast,
its very own DHCPv6 option, SMTP between homenet devices, or carrier pigeon
are possible and encouraged. After all, this is the IETF: there's always
more than one way of doing things, and at least one of them is always a
DHCPv6 option.

But seriously: why are you not comfortable with this idea? We need a
routing protocol for the homenet anyway. A link-state routing protocol can
carry multiple TLVs, including TLVs for DNS servers. Routing protocols can
be authenticated. The devices that need to propagage DNS are likely going
to be home routers. Why not use the routing protocol?

> the received DNS advertisement as both valid and

I don't see a difference. There is no authorization or authentication
today. When you get a DNS server via DHCP, you believe it, or choose not to
believe it, based on no information at all. If there's a rogue DHCP server
on the link that hands you a rogue DNS server, then guess what, you lose.
The only thing that would change here is that you would use HIDP to
distribute that information more than one hop away. Whatever mechanism that
you want to use to authorize and authenticate DNS servers can be used
regardless of whether you learn them via HIDP or via DHCP.

> doesn't require such overloading and complexity.

Well, let's see. You have an ISP that hands you a DNS server using DHCPv6.
You're also connected to a walled garden that hands you a global but
partitioned IPv6 address that can only reach the walled garden, and gives
you its own DNS server. You want things to work more than one hop away. How
would you implement this?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 09:34:17 +0900

On Fri, Oct 26, 2012 at 2:32 AM, Sander Steffann <[email-masked]> wrote:

> Yes. The routing protocol saying 'please use this address to resolve
> google.com' might cause some problems... With DNSSEC in place it can
> still cause a denial of service when unsigned or invalidly signed data is
> returned.
>

No more than a DHCPv6 server saying "please use this DNS server for
everything". Right?

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Oct 2012 08:24:44 +0200

Op 26 okt. 2012, om 02:33 heeft Lorenzo Colitti het volgende geschreven:

> Sorry, I didn't mean "routing protocol". I meant "Homenet DNS Information Distribution Protocol" (HIDP). I would expect a useful way to carry HIDP would be using the homenet routing protocol which the homenet needs to implement anyway, but other implementations such as global IPv6 multicast, its very own DHCPv6 option, SMTP between homenet devices, or carrier pigeon are possible and encouraged. After all, this is the IETF: there's always more than one way of doing things, and at least one of them is always a DHCPv6 option.
> 
> But seriously: why are you not comfortable with this idea? We need a routing protocol for the homenet anyway. A link-state routing protocol can carry multiple TLVs, including TLVs for DNS servers. Routing protocols can be authenticated. The devices that need to propagage DNS are likely going to be home routers. Why not use the routing protocol?
Because we need this info in all nodes. I'm not sure we shall have interactions between hosts and the routing protocol.

> I don't see a difference. There is no authorization or authentication today. When you get a DNS server via DHCP, you believe it, or choose not to believe it, based on no information at all. If there's a rogue DHCP server on the link that hands you a rogue DNS server, then guess what, you lose. The only thing that would change here is that you would use HIDP to distribute that information more than one hop away. Whatever mechanism that you want to use to authorize and authenticate DNS servers can be used regardless of whether you learn them via HIDP or via DHCP.
>  
> Well, let's see. You have an ISP that hands you a DNS server using DHCPv6. You're also connected to a walled garden that hands you a global but partitioned IPv6 address that can only reach the walled garden, and gives you its own DNS server. You want things to work more than one hop away. How would you implement this?
BRDP.

Teco.

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 26 Oct 2012 15:37:25 +0900

Hi,

a DHCPv6 option to deliver such kind of information, that is, relation
between DNS domain names and DNS servers, is almost baked.
https://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-12

Thanks.

2012/10/26 Teco Boot <[email-masked]>:
> But seriously: why are you not comfortable with this idea? We need a routing
> protocol for the homenet anyway. A link-state routing protocol can carry
> multiple TLVs, including TLVs for DNS servers. Routing protocols can be
> authenticated. The devices that need to propagage DNS are likely going to be
> home routers. Why not use the routing protocol?
>
> Because we need this info in all nodes. I'm not sure we shall have
> interactions between hosts and the routing protocol.
>
>
>>
> I don't see a difference. There is no authorization or authentication today.
> When you get a DNS server via DHCP, you believe it, or choose not to believe
> it, based on no information at all. If there's a rogue DHCP server on the
> link that hands you a rogue DNS server, then guess what, you lose. The only
> thing that would change here is that you would use HIDP to distribute that
> information more than one hop away. Whatever mechanism that you want to use
> to authorize and authenticate DNS servers can be used regardless of whether
> you learn them via HIDP or via DHCP.
>
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 15:44:16 +0900

> interactions between hosts and the routing protocol.

You don't need to. You can have interactions between hosts and routers.

> would you implement this?

The question was not how to make routing work in such a setup, the question
was how do you make DNS work such that the walled-garden DNS server (which
could return REFUSED for anything not in the walled garden, like NTT's
does) is used only for that zone.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 15:45:46 +0900

> https://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-12

Sure, but you still need to propagate that information to all the homenet
routers and DHCPv6 servers. In the general case, your host won't be
adjacent to that DHCPv6 server with this information, or it may be using
another DHCPv6 server instead.

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Oct 2012 09:37:26 +0200

Op 26 okt. 2012, om 08:44 heeft Lorenzo Colitti het volgende geschreven:

> The question was not how to make routing work in such a setup, the question was how do you make DNS work such that the walled-garden DNS server (which could return REFUSED for anything not in the walled garden, like NTT's does) is used only for that zone.

BRDP provides pointers to DHCP server for each provisioning domain, where servers may be multiple hops away. Hosts get addresses (DHCP or SLAAC) and then can get the additional info with unicasted DHCP for each address, using the MIF extensions. Maybe we have to tweak DHCP a little to support this.

Teco

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 16:38:45 +0900

On Fri, Oct 26, 2012 at 4:37 PM, Teco Boot <[email-masked]> wrote:

> Hosts get addresses (DHCP or SLAAC) and then can get the additional info
> with unicasted DHCP for each address, using the MIF extensions. Maybe we
> have to tweak DHCP a little to support this.
>

Just "maybe" ? :)

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Oct 2012 09:39:59 +0200

Op 26 okt. 2012, om 08:45 heeft Lorenzo Colitti het volgende geschreven:

> On Fri, Oct 26, 2012 at 3:37 PM, Arifumi Matsumoto <[email-masked]> wrote:
> Sure, but you still need to propagate that information to all the homenet routers and DHCPv6 servers. In the general case, your host won't be adjacent to that DHCPv6 server with this information, or it may be using another DHCPv6 server instead.

No, BRDP and MIF-stack solves this.
All routers in Homenet forward the Border Router (which is also DHCP server or relay).
DHCP info is never merged, nodes get the info one by one, for each provisioning domain.

Teco

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 16:47:11 +0900

> DHCP info is never merged, nodes get the info one by one, for each

Ok, but then you need to change the hosts to implement the MIF stack?

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Oct 2012 09:50:13 +0200

Op 26 okt. 2012, om 09:38 heeft Lorenzo Colitti het volgende geschreven:

> Hosts get addresses (DHCP or SLAAC) and then can get the additional info with unicasted DHCP for each address, using the MIF extensions. Maybe we have to tweak DHCP a little to support this.
> 
> Just "maybe" ? :)

We have to do something, OK? Better just tweak than do it all over again.

The question is, does DHCP support the following: The MIF node has configured a bench of addresses with SLAAC. Now it learns that there is a DHCP server somewhere that has important info for the provision domain for one of the addresses. Can the node get this info, with the already configured address for that provisioning domain, with a unicast? Nodes will be updated anyway for MIF, so let's go for it. Far better than merging info from multiple provisioning domains into a single DHCP server. Not?

Teco

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Oct 2012 09:55:36 +0200

> Ok, but then you need to change the hosts to implement the MIF stack?

I suggest we kindly ask MIF WG to take care. It is in their scope to better support multihoming. Then, we can focus on home network gear and the protocols to get needed info to all nodes, including the MIF hosts.

Teco

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 17:05:19 +0900

On Fri, Oct 26, 2012 at 4:50 PM, Teco Boot <[email-masked]> wrote:

> The question is, does DHCP support the following: The MIF node has
> configured a bench of addresses with SLAAC. Now it learns that there is a
> DHCP server somewhere that has important info for the provision domain for
> one of the addresses. Can the node get this info, with the already
> configured address for that provisioning domain, with a unicast? Nodes will
> be updated anyway for MIF, so let's go for it. Far better than merging info
> from multiple provisioning domains into a single DHCP server. Not?
>

Can we get by without a DHCPv6 server at all?

DHCPv6 servers are stateful and DHCPv6 is a protocol based on promises that
are valid for a predetermined amount of time. In a homenet, DHCPv6 servers
(i.e., CPE routers) may be plugged in and unplugged any time, and there is
no way to invalidate their information, which means the hosts are stuck.

Using a routing protocol and not using DHCPv6 solves this issue, because a
router is allowed to deprecate a prefix that has gone away even if it was
originally announced by someone else, and NUD will let hosts work around
broken routers in a reasonable amount of time.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 26 Oct 2012 17:09:17 +0900

> broken routers in a reasonable amount of time.

Forgot to mention: the presentation I attached (which was given at the
homenet meeting in October 2011) tries to do that with RAs and routing
protocol only. In many ways it's similar to BRDP.

I was going to remove the attachment because I realized that it's already
archived -
http://www.ietf.org/mail-archive/web/homenet/current/msg00385.html - but I
forgot.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 26 Oct 2012 10:18:06 +0200

> No more than a DHCPv6 server saying "please use this DNS server for everything". Right?

Right.

---

From: Teco Boot <[email-masked]>
Date: Fri, 26 Oct 2012 10:43:11 +0200

> Can we get by without a DHCPv6 server at all?
In the Homenet BRDP draft, I removed the BRIO suboptions and emphasized DHCP.
So yes, it can be done, with ND RA options. I'm afraid it is hard to get it right for existing hosts.

> 
> DHCPv6 servers are stateful and DHCPv6 is a protocol based on promises that are valid for a predetermined amount of time. In a homenet, DHCPv6 servers (i.e., CPE routers) may be plugged in and unplugged any time, and there is no way to invalidate their information, which means the hosts are stuck.
BRDP provides mapping between routers and prefixes. When border router is not reachable anymore, or prefix gets invalid, routers should inform hosts with ND PIO. This will work with existing hosts. DHCP info is not invalidated, it just isn't used anymore.

> 
> Using a routing protocol and not using DHCPv6 solves this issue, because a router is allowed to deprecate a prefix that has gone away even if it was originally announced by someone else, and NUD will let hosts work around broken routers in a reasonable amount of time.
> <Homenetstrawman.pdf>

A difference in BRDP and the strawman proposal is default gw route vs. walled garden more specific. I suggest handling both equivalent. In a way that is a tiny tweak in forwarding heuristic. Open for discussion. Many other BRDP functions are exactly as the proposal.

I missed the meeting where this was presented. Bad luck.

(BTW: BRDP is from far before Homenet, it was parked for a while...)

Teco

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 26 Oct 2012 11:59:52 -0400

On 25  Oct 2012, at 20:33 , Lorenzo Colitti wrote:
> I don't see a difference. There is no authorisation or
> authentication today. When you get a DNS server via DHCP,
> you believe it, or choose not to believe it,
> based on no information at all.

1) DHCP Authentication is standardised. [RFC 3118]  
  Multiple implementations of DHCP Authentication exist.  
  So this can be deployed/used in environments where 
  DHCP Authentication is deemed sensible.

2) DNS Security is standardised. [RFC 4033 et alia].
   Multiple implementations of DNSsec exist.  Deployment
   of DNSsec is growing much faster than initially
   expected.  So this can be deployed/used in environments
   where DNS Authentication is deemed sensible.

3) It appears that DNSsec still can be used with mDNS.
   So again, this can be deployed/used in environments
   where DNS authentication is deemed sensible.

So, a proposal with no capability to authenticate
information, or address authorisation issues, seems
very much like a non-starter.  At the very least,
authentication needs to be specified/available,
and the authorisation issues need to be addressed.

> If there's a rogue DHCP server on the link that hands you
> a rogue DNS server, then guess what, you lose.

This is not true if DHCP Authentication has been deployed.
Instead, the quote above is a very good supporting justification
for comments that we need to specify mechanisms both that 
can provide authentication and do address authorisation issues.

(From a different, purely practical, perspective)

I would guess that any proposal with less security capability 
than we have today (i.e. with DHCP Authentication, DNSsec) 
would be rejected by the IETF Security Area when they perform 
their Area Review (which is usual prior to IESG approval 
of any IETF track document). 

Yours,

Ran

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Oct 2012 12:09:48 -0400

>    where DNS authentication is deemed sensible.

Let us be perfectly clear on this: mDNS is a completely different
protocol, on a different port.  Moreover, DNSSEC cannot be used for
validation with mDNS because the actual mDNS name is [some
string].local., and local. is not signed (and if it were, everything
would fail validation, unless you install a special trust anchor).

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Oct 2012 17:24:40 +0100

Not trying to get into the argument here, but just one
point:

> This is not true if DHCP Authentication has been deployed.

My understanding is that 3118 is fictional, i.e. is never
deployed, ever. As an AD, I generally push back on any
draft where the security considerations say "use 3118
and you'll be fine."

If I'm wrong, I'd be interested in knowing that and
about when/where 3118 is being used.

Ta,
S.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 26 Oct 2012 12:46:29 -0400

On 26  Oct 2012, at 12:24 , Stephen Farrell wrote:
> My understanding is that 3118 is fictional,
> i.e. is never deployed, ever.  As an AD, I generally
> push back on any draft where the security considerations
> say "use 3118 and you'll be fine."
> 
> If I'm wrong, I'd be interested in knowing that
> and about when/where 3118 is being used.

I've been told about deployments within certain 
governmental networks in more than one country.  

So my understanding is that it is not "fictional".

Yours,

Ran

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Oct 2012 09:51:00 -0700

> So my understanding is that it is not "fictional".

I think the larger question is whether "just use secure-X" is a fiction within
a homenet environment. Given that "secure-X" is often a fiction within
networks with nominal clue, I think we should be skeptical of just about
anything that requires any clue at all. DNSSec, for example: what does
that even mean in the face of zero clue?

Mike

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Oct 2012 17:01:44 +0900

Ran,

I think you're missing the point. What I am suggesting is that the routers,
which learn DNS servers via DHCPv6 or RDNSS, can pass around those DNS
servers inside the routing protocol that runs in the homenet. The hosts
would then get the information from the routers using DHCPv6 or RDNSS, just
like they do today.

The routing protocol can be secured in the usual ways that routing
protocols are secured (e.g., using MD5 secrets).

I really don't see what security issues this introduces.

Cheers,
Lorenzo

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Oct 2012 09:37:34 -0400

> So my understanding is that it is not "fictional".

Interesting...I've not heard of this deployment before.  I'd be interested to know how they manage the shared keys.

- Ralph