Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt

[Ralph Droms <rdroms@cisco.com>]

Pekka - comments in line...

- Ralph

At 03:08 PM 3/22/2004 +0200, Pekka Savola wrote:
> On Fri, 19 Mar 2004, Ralph Droms wrote:
> > In section 4.1.2, while the statement "The basic use of DHCP is insecure."
> > is technically true, it does not apply to the discussion of DHCPv6 prefix
> > delegation.  Section 15 of RFC3396 gives specific guidelines for the 
> use of
> > DHCPv6 authentication for DHCPv6 PD.  DHCPv6 authentication is defined as
> > part of the base DHCPv6 specification, in section 21 of RFC3315.
>
> Right.
>
> > The statement "To be useful in such environment in practice, the practical
> > details of managing the DHCP authentication need to be analyzed." needs to
> > be explained.  How is the authentication specified in RFC3315 and
> > recommended for DHCPv6 PD in RFC3396 not adequate?
>
> (Operational) key management seems problematic, even though DHCP
> provides support for that.

How is operational key management for the authentication mechanism described
in RFC3315 more problematic than for other mechanisms that use shared keys?

> Maybe reword:
>
>    The basic use of DHCP is insecure. This may be a problem if the link
>    between gateway and ISP is shared by multiple subscribers. DHCP
>    specification includes authentication options, but does not describe
>    the task of managing the keys, and how the information would be
>    shared between the customer and the ISP.  To be useful in such
>    environment in practice, the practical details of managing the DHCP
>    authentication need to be analyzed.
>
> to:
>
>    DHCP is insecure unless authentication is used. This may be a
>    particular problem if the link between gateway and ISP is shared by
>    multiple subscribers. DHCP specification includes authentication
>    options, but the operational procedures for managing the keys and
>    methods for sharing the required information between the customer
>    and the ISP are unclear.  To be secure in such environment in
>    practice, the practical details of managing the DHCP authentication
>    need to be analyzed.
>
> Perhaps that is a bit more fair statement of the issue(s) involved.

No, I honestly don't think it's any more fair.  Most service providers
provide complete isolation of customer traffic through filtering even if the
link appears to be shared among multiple customers.  If customers do truly
share a link, there are *many* other attacks available and pointing out DHCP
as a specific problem is only telling part of the story.  Finally, I still
haven't heard an explanation of the requirement that "the practical details
of managing the DHCP authentication need to be analyzed."  DHCP can use a
password provided by the service provider to the customer.  What additional
analysis do we need to perform?

The issue of DHCPv6 security is adequately addressed in RFC3315 and need
not be rehashed here.  Anyone who reads RFC3315 (btw, the reference
[DNSDHCPV6] is never cited anywhere in the body of the document) will
see the security analysis for DHCPv6.

> > What are the security implications of ND proxy?
>
> Roughly equal or slightly worse, but then again, it would probably not
> be applicable in this specific ("multiple subscribers in one big LAN")
> environment in any case.

So ND proxy doesn't represent a security problem and requires no
authentication because its scaling properties preclude its use in what you
consider to be a typical deployment scenario?  Whatever the situation,
the security issues for ND proxy should be mentioned as well as those
for DHCPv6.

> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings