Subject: [homenet] Border discovery without DHCP-PD

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 13:28:13 +0200

Reading Section 5 again, I don't see a way to force a link to be external
without providing either stateful DHCPv4 or stateful DHCPv6-PD.

Should there be some stateless protocol one can run on a link in order to
force all HNCP routers to treat the link as external?

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 06 Jul 2015 13:32:10 +0200

> without providing either stateful DHCPv4 or stateful DHCPv6-PD.

HNCP mandates that manual configuration of interface categories MUST be possible.

> force all HNCP routers to treat the link as external?

I don't think inventing yet another protocol makes sense here.
What is your usecase here?

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 13:45:39 +0200

> What is your usecase here?

Remember all the trouble we had with rogue RAs?  An RA-killer protocol
built-in from the start would have avoided all of that, so I'm thinking of
an HNCP-killer protocol.  Nothing complicitated, just react to any HNCP
packet by unicasting an HNCP packet with a KILLER TLV.  Periodic KILLER
multicasts might be a good idea.

If we don't do that, we'll gather a lot of bad press by breaking operational
networks when stateful DHCP fails for some reason, with no easy way to
work around that.

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 06 Jul 2015 14:03:31 +0200

> networks when stateful DHCP fails for some reason, with no easy way to

Can you elaborate a bit more on the breaking operational network
parts (not in the RA-sense but for HNCP)? I mean a concrete
use-case or example of what would break or how?

In general auto border discovery is a heuristic to increase
user-friendliness, and it uses protocols that ISPs usually speak with us.

At the moment it is also decoupled from HNCP in a sense that HNCP
is only enabled after the interface category is determined to be internal.

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 14:24:38 +0200

> use-case or example of what would break or how?

One of the interfaces, say eth1, is connected to an IPv6-only network that
doesn't do DHCPv6-PD.  Another one is connected to an HNCP network, with
some other router publishing an IPv6 prefix delegation.

                      eth1
  IPv6-only network ----- me ----- (HNCP network) ----- HNCP router with PD

Since there's neither DHCPv6-PD nor DHCPv4 on the IPv6-only network, eth1
is detected as internal.  Since there's an IPv6 prefix delegation, the
HNCP daemon allocates a /64 to each link connected to each of its internal
interfaces and starts sending RAs on eth1.

I'm now sending RAs on a production network, with no way for the network
administator to prevent that short of either (1) reconfiguring my router
(and any other Homenet routers that might be connected to this network),
or (2) enabling stateful DHCPv4 or DHCPv6-PD.

So please either define a new RA option that triggers HNCP border discovery,
or define a new HNCP-killer TLV:

  while(1) {
     sendmsg(KILLER)
     sleep(random() % 16)
  }

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 06 Jul 2015 14:43:57 +0200

> or (2) enabling stateful DHCPv4 or DHCPv6-PD.
I'm sorry, to me this seems a bit farfetched to blame this case on HNCP.
If you would have connected any device that serves RA / DHCP on that
interface you would have the exact same results. Since that can happen
even with the HNCP router in place you would need to deal with it anyway.

Plus if a rogue RA / DHCP on one link breaks your whole "production
network" you probably have other issues besides that.

Personally I don't see the point here, to add logic and complexity to address
this in HNCP - it just looks like the wrong place to fix it unless the general
consensus is different.

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 14:54:52 +0200

> this in HNCP - it just looks like the wrong place to fix it

What do you have in mind?

-- Juliusz

---

From: Erik Kline <[email-masked]>
Date: Mon, 6 Jul 2015 21:57:35 +0900

> is only enabled after the interface category is determined to be internal.

Eh?!  I missed that.  That's not at all what I would have done (and
not what I had proposed).

My suggestion, updatd with the name "HNCP" now that we have it, was
basically that HNCP discovery should be done all the time, and if an
authenticated adjacency could be formed then that was input to whether
the link was going to be considered internal or not.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 15:02:45 +0200

> the link was going to be considered internal or not.

That breaks if you have multiple border routers on the same external link.

-- Juliusz

---

From: Erik Kline <[email-masked]>
Date: Mon, 6 Jul 2015 22:08:43 +0900

On 6 July 2015 at 22:02, Juliusz Chroboczek
<[email-masked]> wrote:
>> authenticated adjacency could be formed then that was input to whether the
>> link was going to be considered internal or not.
>
>

Which is why that exact case was designated external.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 15:15:54 +0200

> Which is why that exact case was designated external.

Sorry if I missed the original discussion.

How does your scheme deal with stub links, on which there are no HNCP
neighbours, just hosts?

How does your scheme deal with the following topology?

                      +---- B ---
                      |
  Internet ---- A ----+            Homenet
                      |
                      +---- C ---

where A is a non-Homenet DHCPv4 and DHCPv6-PD server, while B and C are
Homenet routers, wouldn't your scheme cause B and C to consider their
interfaces as internal?

-- Juliusz

---

From: Erik Kline <[email-masked]>
Date: Mon, 6 Jul 2015 22:29:01 +0900

The intent was to have B and C each thing of their interface toward as
external.  Period.  If they detect that they could form an adjacency
on that interface then they could warn a user about the
misconfiguration.

It's all very, very, very old now, but:

    https://tools.ietf.org/html/draft-kline-homenet-default-perimeter-00
    http://www.ietf.org/proceedings/84/slides/slides-84-homenet-7.pdf

The questions at the end of the slides were discussed, and my
recollection is that Dave Thaler suggested, and the room agreed, that
it just be declared inherently insecure, document it, warn, and move
on.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 15:46:00 +0200

>     http://www.ietf.org/proceedings/84/slides/slides-84-homenet-7.pdf

My reading of hncp-06 is that we're supposed to do what you suggested
(including continuous monitoring), except that no warning is logged if
a DNCP adjacency is established over the external interface.

Markus, Steven -- should DNCP synchronisation happen over the external
link in that case?  My reading is that it should, but I may have missed
something.

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 06 Jul 2015 16:57:22 +0200

> a DNCP adjacency is established over the external interface.
Yes, there is continuous monitoring for new borders on all interfaces
with automatic border discovery.

> link in that case?  My reading is that it should, but I may have missed

No, by default that does not happen, i.e. HNCP and IGP are not run on external links.
However there is a _manual_ override in the form of the optional "hybrid" category.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 18:57:57 +0200

> I'm sorry, to me this seems a bit farfetched to blame this case on HNCP.

Steven, nobody is speaking about blaming HNCP.

I am asking for a new feature that makes it possible for a network
administrator to easily disable HNCP on a given link.  I don't see how
that can be achieved otherwise.

If it can be achieved without changes to HNCP, please let me know how.

> to add logic and complexity to address this in HNCP

It's 20 lines of code, Steven.  The KILLER TLV has the following format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Milliseconds                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If a KILLER TLV is received on a given interface, then this interface MUST
be put into external mode for at least the given number of Milliseconds.
If the interface is in authenticated mode, then the KILLER TLV MAY be
ignored unless it was received over unicast with proper authentication.

The idea being that by default all Homenet routers obey unauthenticated
KILLERs, but that they can be configured to ignore unauthenticated ones.
An hncp-killer works by sending periodic multicast KILLERs, and optionally
by sending unicast KILLERs upon receiving a NETWORK-STATE.

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Jul 2015 13:27:48 -0400

Juliusz Chroboczek <[email-masked]> wrote:
    >> I don't think inventing yet another protocol makes sense here.  What
    >> is your usecase here?

    > Remember all the trouble we had with rogue RAs?  An RA-killer protocol

So, the problem is that if we have a RA-killer protocol, then we have a
potential DoS from a "compromised" internal host.   Maybe that's a good
thing, if that LAN goes down, then the compromised host is disconnected
too...  or maybe it's a problem that mom and dad are going to have to deal
with.

What it means is that this RA-killer will have to be advisory.  This
is really akin to the "there is no IPv4 here" message that some Sunset4
wanted to have.

It seems to me that sending this RA-killer HNCP message is no more or less
complicated than answering with a null DHCPv[46] offer for an ISP.
(It's all new code)

... but I understand your desire to keep RAs off networks where they do not
belong.  Perhaps RAs (and IPv6 prefix allocation) should be suppressed on
networks on which no IPv6 traffic has been seen, and no RSs have ever
occured.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Jul 2015 09:29:34 +1200

On 07/07/2015 05:27, Michael Richardson wrote:

...
> networks on which no IPv6 traffic has been seen, and no RSs have ever

Once IPv4 is put out of its misery, that would be the null set, wouldn't it?

  Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jul 2015 17:31:27 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> ... but I understand your desire to keep RAs off networks where they
    >> do not belong.  Perhaps RAs (and IPv6 prefix allocation) should be
    >> suppressed on networks on which no IPv6 traffic has been seen, and no
    >> RSs have ever occured.

    > Once IPv4 is put out of its misery, that would be the null set,

Presence of RA(?I think?) or DHCPv6(PD) would cause the network to be seen as
an external network, and would therefore turn off HNCP on that interface.

If some host is sending RSs and there are no RAs in answer, then the network
may be waiting for HNCP to come up and provide service.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jul 2015 09:50:24 +1200

> an external network, and would therefore turn off HNCP on that interface.

I don't see why RAs would do that. RAs are a required feature of an IPv6
network, regardless of whether it has external connectivity.

IMHO it would be perfectly OK for a router that comes up and finds itself
without any friends or uplinks to invent a ULA prefix and start RAs.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jul 2015 10:22:00 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> Brian E Carpenter <[email-masked]> wrote: >> ... but I
    >> understand your desire to keep RAs off networks where they >> do not
    >> belong.  Perhaps RAs (and IPv6 prefix allocation) should be >>
    >> > Once IPv4 is put out of its misery, that would be the null set, >
    >> wouldn't it?
    >>
    >> Presence of RA(?I think?) or DHCPv6(PD) would cause the network to be
    >> seen as an external network, and would therefore turn off HNCP on that
    >> interface.

    > I don't see why RAs would do that. RAs are a required feature of an
    > IPv6 network, regardless of whether it has external connectivity.

The point is to provide a *heuristic* that prevents HNCP from turning on IPv6
RAs on a network which is otherwise managed by another device.

The presence of RAs on a network (with an absense of HNCP messages) is a
signal that something else is managing that network.
If there was also DHCPv6-PD, then the heuristic already knows that.

    > IMHO it would be perfectly OK for a router that comes up and finds
    > itself without any friends or uplinks to invent a ULA prefix and start
    > RAs.

Yes, it would.. it doing that (and not having HNCP) would be a sign that HNCP
should not (by default) turn on RAs on that network.