Subject: [v6ops] DHCPv6/IPV6ND and SEND (was: RE: New Version Notification for draft-naveen-slaac-prefix-management-00.txt)

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 20 Nov 2018 00:06:46 +0000

Hi Ole,

Another benefit for including DHCPv6 messages as options within IPv6ND
RS/RA messages is that Secure Neighbor Discovery (SEND) can be used to
secure the message exchange. And, the Nonce option value can serve
as an enhanced transaction ID to supplement the 24-bit value in the
DHCPv6 message header.

So, in addition to the advantages already discussed, using DHCPv6 in
conjunction with IPv6ND provides benefits not available by using
DHCPv6 separately from IPv6ND.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Wednesday, November 14, 2018 8:54 AM
> To: Ole Troan <[email-masked]>
> Cc: v6ops list <[email-masked]>; 6man WG <[email-masked]>
> Subject: RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
> 
> Hi Ole,
> 
> > -----Original Message-----
> > From: Ole Troan [mailto:[email-masked]]
> > Sent: Wednesday, November 14, 2018 8:32 AM
> > To: Templin (US), Fred L <[email-masked]>
> > Cc: v6ops list <[email-masked]>; 6man WG <[email-masked]>
> > Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
> >
> > Fred,
> >
> > > On 14 Nov 2018, at 16:38, Templin (US), Fred L <[email-masked]> wrote:
> > >
> > > Ole,
> > >
> > > You didn't respond to my point which is really at the heart of the matter:
> > >
> > >>>> It is also important that there are fewer messages - two instead of four. That matters
> > >>>> a great deal on low end links.
> > >>>
> > >>> I would like to see the maths behind that.
> > >>> Use header compression then.
> > >>
> > >> It isn't only a question of how many bytes - the question is moreso how
> > >> many channel accesses are necessary. On some links, sending everything in
> > >> a single channel access is less prone to collisions than requiring multiple
> > >> channel accesses.
> > >
> > > Fewer messages are fewer messages. On congested links with lots of
> > > channel contention that is an important consideration.
> >
> > If this is such a big concern, what are you doing with all the other ND chatter?
> 
> DAD is disabled, because there is operational assurance that addresses will
> be unique. NUD is not needed either. All that is needed is RS/RA.
> 
> > Perhaps you should drop ND on these links and do only DHCP? :-)
> 
> DHCPv6 does not deliver default router lifetime, on-link prefix information,
> SLLAO, nor any other parameters carried uniquely by RS/RA. We need
> that information.
> 
> > Or preconfigure everything so you don’t need to send any packets at all?
> 
> There are use cases where a mobile node such as an airplane is pre-provisioned
> with a Mobile Network Prefix (MNP). But, when the node comes onto the
> network it still needs to register its MNP with the network so that the network
> will set up the correct routing information. DHCPv6 PD is a good way to do that.
> 
> > Do you have data on the behavior of this link type, showing the effects you are referring to?
> 
> The reality for today and into the near future is that we have 32Kbps for VHF
> terrestrial cellular and 256KB for SATCOM. For the longer term, there may be
> new SATCOM services as well as 1Mbps for a future terrestrial cellular link that
> may or may not ever be deployed.
> 
> But, what is good in this environment applies more broadly to other more
> robust environments. Fewer messages is still fewer messages.
> 
> Thanks - Fred
> 
> > Cheers
> > Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Nov 2018 03:06:44 -0300

Fred,

It would seem to me that while we do have a spec for "SEND", there seems
to be close to null host support for SEND. I'd also argue that SEND has
a very small ROI -- particularly when lots of other pieces of the
"puzzle" remain to be secured.

Note: the above is a comment about this particular argument, and *not*
an argument against including DHCPv6 options in ND messages.

Thanks,
Fernando

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Nov 2018 15:28:03 +0100

Le 20/11/2018 à 07:06, Fernando Gont a écrit :
> to be close to null host support for SEND.

Yet the need of secure neighbor discovery is huge.

What's the most straightforward way to secure an RA very quickly now on 
the command line?

Alex

---

From: "Anderson, Charles R" <[email-masked]>
Date: Tue, 20 Nov 2018 14:32:03 +0000

> What's the most straightforward way to secure an RA very quickly now on 

Filter it on all untrusted switch ports.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 20 Nov 2018 15:01:16 +0000

On 20 Nov 2018, at 14:28, Alexandre Petrescu wrote:

> What's the most straightforward way to secure an RA very quickly now 
> on the command line?

There’s (3rd party) SeND support for most desktop/server operating 
systems.

/bz

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 20 Nov 2018 15:37:43 +0000

Hi Fernando,

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Monday, November 19, 2018 10:07 PM
> To: Templin (US), Fred L <[email-masked]>; Ole Troan <[email-masked]>
> Subject: Re: DHCPv6/IPV6ND and SEND (was: RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt)
> 
> Fred,
> 

There needs to be a securing service for both IPv6ND and DHCPv6 to protect
the protocols. That means that, by unifying the two protocols, there only needs
to be one securing service; not two. SEND seems like a likely candidate.

Thanks - Fred

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 20 Nov 2018 16:04:21 +0000

Hi,

> From: v6ops [mailto:[email-masked]] On Behalf Of Anderson, Charles R
> Sent: Tuesday, November 20, 2018 6:32 AM
> To: [email-masked]
> Subject: Re: [v6ops] DHCPv6/IPV6ND and SEND (was: RE: New Version Notification for draft-naveen-slaac-prefix-management-00.txt)
> 

IPv6 ND trust models and threats that motivate SEND are in RFC3756.

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

---

From: "Anderson, Charles R" <[email-masked]>
Date: Tue, 20 Nov 2018 16:33:35 +0000

> IPv6 ND trust models and threats that motivate SEND are in RFC3756.

Let me rephrase my answer to this question:

"What's the most straightforward way to secure an RA very quickly now on the command line?"

In today's enterprise LANs, RFC6959 SAVI implementations are more available and straighforward to deploy very quickly than RFC3756 implementations.  No changes to end hosts are required.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 20 Nov 2018 16:44:49 +0000

> From: Anderson, Charles R [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2018 8:34 AM
> Cc: [email-masked]
> In today's enterprise LANs, RFC6959 SAVI implementations are more available and straighforward to deploy very quickly than RFC3756
> implementations.  No changes to end hosts are required.

Today's enterprise LANs are an example of a secured link type, where link
layer securing mechanisms such as IEEE 802.1X can be used. Not all link
types can be secured at the link and/or physical layer.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Nov 2018 12:46:30 -0300

> to be one securing service; not two. SEND seems like a likely candidate.

"Securing" as in being able to validate advertised data? Or as in
"preventing e.g. a node to pretend it's a local router or dhcpv6 server"?

Thanks,
Fernando

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 20 Nov 2018 21:56:53 +0000

Hi Fernando,

> Sent: Tuesday, November 20, 2018 7:47 AM

Security at the IPv6ND level is as-specified in RFC3971, i.e., SEND is used
to "protect the integrity of the messages and authenticate the identity
of their sender".

In terms of DHCPv6, it means that the client can be assured that the
relay/server is who it claims to be, and therefore the client can accept
any configuration information handed down. It also means that the
server cannot be spoofed into delegating information intended for
a trusted client 'A' to a rogue client 'B' who is pretending to be 'A'.

Does that answer your question?

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Nov 2018 13:47:59 +0100

Le 20/11/2018 à 16:01, Bjoern A. Zeeb a écrit :
> There’s (3rd party) SeND support for most desktop/server operating systems.

And "iSEND: IPv6 SEcure Neighbor Discovery Implementation for Android 
Devices" ambitions to deliver before 2019.

Alex