Subject: Re: [Anima] comments on prefix delegation and GDN protocol document

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Dec 2014 13:43:27 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> wrt: the GDN protocol and requirements:
    >>
    >> 5.2.1:  why does the GDN protocol need to run over IPv4?
    >> I would agree that it might need to configure IPv4 services, but I can't
    >> see a reason why it should be complicated by the need to support legacy
    >> 32-bit stuff.

    > Because the context is the whole Internet, and although my instinct is
    > the same as yours, I don't think it's realistic for the next ten or twenty
    > years to assume IPv6 transport everywhere.

I said: no IPv4, only IPv6, you understood the opposite.
I didn't think that GDN needed to run other than across layer-2 fabrics
(single hops).  I didn't think it needed to across the Internet.

    >> 5.2.3.1: algorithm agility, you can't say: don't fallback to an algorithm
    >> considered weak.  If the software author knew the algorithm was
    >> weak at the time the code was written, the algorithm would
    >> not have been included.  That's the whole problem here: you need to
    >> be able to incrementally deploy new algorithms, so you need an
    >> upgrade mechanism, and you *have to* fallback when the other node
    >> does not support stronger algorithm, and the attacker will
    >> convince you...
    >>
    >> The only out is that you can do something in the certificates
    >> that says what ought to be supported.

    > We've also got policy intent in the future too, like an intent that
    > says "Don't accept algorithm X any more."

    > (Doesn't putting it in the cert mean that you need to be very sure that
    > certificate revocation will work? Well, I guess that needs to work
    > anyway.)

If a hash algorithm is weak/defeated, then in effect, all of the certificates
that signed with that algorithm are weak.  It's easier to say, signed{I support SHA2}
than it is to say the opposite.

    >> While we pretend via Layer-2 devices that ethernet is
    >> still made up of broadcast coax cables, except for wifi, there are probably
    >> only two devices connected at each end of the cable.

    >> So I suggest that while a multicast based discovery protocol is appropriate
    >> (and why not use DHCPv6 or RPL), once the end point is discovered, it seems
    >> that one should run GNDP over point to point DLTS or IPsec.

    > Yes, once you have identified the counterpart it should be unicast
    > and secure.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Dec 2014 13:45:04 -0500

Sheng Jiang <[email-masked]> wrote:
    > Thanks for your comments. The replies in lines.

    > From: Anima [mailto:[email-masked]] On Behalf Of Michael
    >> Richardson
    >>
    >> section 3.1
    >> why send a GDN discovery message asking for a Prefix Option, instead of just
    >> sending a DHCPv6 Discovery message with PD as a request?

    > The DHCPv6 PD does not work with DHCPv6 discovery message, by
    > definition. RFC3633 (DHCPv6 PD) is actually working between routers,
    > rather than traditional DHCPv6 server/client. So, DHCPv6 PD is based on
    > the assumption, the requesting router already know the request router,
    > that's where to send the prefix pd request. Section 3.1 describes a
    > behavior to discover the request router using GDN protocol.

Uhm, can't I say, in a DHCPv6 Discovery message, that I'm interested in
replies from a DHCPv6 server that is willing to provide me with Option X,
and I can set X=PD?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2014 08:02:45 +1300

> (single hops).  I didn't think it needed to across the Internet.

It needs to run across a whole administrative domain; there is
no restriction to a single layer 2 link. Maybe we need to make
that more clear at the beginning.

Certainly there will be use cases confined to a single link, but if
you are managing a resource that is network-wide, you need to
negotiate with counterparts anywhere in the network.

>     >> does not support stronger algorithm, and the attacker will

I think that's exactly the point. You might install a new network-wide policy
that says NEVER accept single DES - simply abandon communication with a node
that can only do single DES. If that's the policy, the legacy nodes will
fall off the network, and that is the desired result.

> than it is to say the opposite.

Indeed.
   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 9 Dec 2014 01:45:14 +0000

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
>Richardson

Hi, Michael,

By definition of protocol, yes, it is possible. But, in the real deployment, this has to depend on a precondition that the requesting router and the delegating router are directly connected and there is no other path. (The DHCPv6 Discovery mechanism can discovery DHCPv6 server using preconfigured DHCPv6 relay, but this mechanism does not suitable to discovery the requesting router.) In other word, the DHCPv6 Discovery mechanism does not support autonomic discovery requesting routers in a flexible topology environment, which is the essence of autonomic network. Therefore, we need a GDN discovery message with its associated discovery mechanism, which can work in various topology networks, to find out the delegating router. Only after then, it is possible to request a prefix. Whether it uses DHCPv6 PD or a new option in GDN is another discussion.

Best regards,

Sheng

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Dec 2014 15:00:43 -0500

Sheng Jiang <[email-masked]> wrote:
    > By definition of protocol, yes, it is possible. But, in the real
    > deployment, this has to depend on a precondition that the requesting
    > router and the delegating router are directly connected and there is no
    > other path. (The DHCPv6 Discovery mechanism can discovery DHCPv6 server

I'm trying to understand the situation where GDN isn't run hop-by-hop.
Perhaps I missed this part.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Dec 2014 11:21:10 +1300

> Perhaps I missed this part.

That's the Divert mechanism. We'll try to make it clearer in the
next version of the draft (which will be very different, hence
it's taking time to get it ready).

For now: GDN is peer-to-peer, but the peer could be anywhere
within the same administrative+security domain. (This is a
significant difference from HNCP, or at least from HNCP as
currently described).

   Brian

   Brian