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

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Nov 2014 16:12:30 -0500

I read these on the airplane.

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?

Is there a way to get a prefix that isn't DHCPv6PD?
I guess section 3.3 leaves this as an open question... I would say, either do
DHCPv6, or don't, but run a protocol to decide if you are going to run a
protocol.

I'm unclear if the prefix being allocated is for production use, or is for
numbering the control channel(s).

I will note that if one uses RPL to build a control channel, that RPL also
can distribute prefixes in PIOs.

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.  
    I would suspect that the GDN protocol might run in the supervisor
    processor for a router/switch/server (server: I'm thinking IBM Service
    Processor, DELL iDrac, as well as in the control plane processor of a
    router), so I can't see an installed base reason for IPv4/32-bit support

5.2.3: I think the GNDP should run over DTLS or IKEv2/IPsec (pick one), and
       that the certificates involved should key that channel rather than
       invent a new one.

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.

As far as I can see the only reason to use assymetric signatures on each
message is in order to support multicast.

My understanding is that this protocol will primarily occur between adjacent
routing equipment.  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.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Nov 2014 11:03:41 +1300

Focussing on GDN; I will leave Sheng to comment on the prefix delegation case:

On 24/11/2014 10:12, Michael Richardson wrote:
...
>     see a reason why it should be complicated by the need to support legacy

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.

>     router), so I can't see an installed base reason for IPv4/32-bit support

GDN could run anywhere, really. That's what the "G" means, isn't it?

>        that the certificates involved should key that channel rather than

Personally I'm open to not reinventing wheels. I regard this area as very liable
to change, and it needs to be fully compatible with the trust bootstrap stuff
too.

>          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.)

> routing equipment.  

I don't have that understanding. Actually we specifically want to assume
as little as possible, and we specically want to be able to reach more
distant peers if they are the best negotiation counterpart for some resource.

> While we pretend via Layer-2 devices that ethernet is

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

Thanks!

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 24 Nov 2014 09:28:26 +0000

Hi, Michael,

Thanks for your comments. The replies in lines.

>From: Anima [mailto:[email-masked]] On Behalf Of Michael
>Richardson
>
>section 3.1

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.

>DHCPv6, or don't, but run a protocol to decide if you are going to run a

So far, the DHCPv6 PD seems only way to get a prefix, unless we also support it using GDN. The section point of section 3.3 is not whether run DHCPv6PD. The point is to decide which device to request a prefix and whether that device has enough resource. If no, whether change the requested device or settle down with a smaller prefix.

>numbering the control channel(s).

Both usages are covered by the same procedure.

>can distribute prefixes in PIOs.

The advertisement of prefix information, in ND or RPL, is very different from prefix delegation. The former is a flooding information. The prefix is shared by any nodes that received the prefix information. The latter is to delegate a prefix to the received node only. Furthermore, we also need to transfer the prefix among multiple repositories.

Best regards,

Sheng