Subject: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt

From: Ralph Droms <[email-masked]>
Date: Wed, 28 May 2003 15:23:25 -0400

(This is a re-send as the first posting may not have been
forwarded through the dhcwg mailing list - RD)

At 11:54 AM 5/14/2003 -0400, Thomas Narten wrote:
> I've completed my review AD review of this document prior to starting
> the IETF LC. I have one (possibly) substantative question, the rest
> are nits.
>
> In reading the document, there is some wording that suggests that a
> requesting router might ask for prefixes for each of its
> interfaces. E.g, if it has two internal interfaces, plus the link to
> the ISP, it might ask for two delegations, one for each internal
> interface. But this isn't what I would expect normal usage to be.
> Rather, I'd expect the requesting router to ask for a single
> delegation, based on the one interface it has to its ISP, and would
> itself decide how to further delegate to its internal interfaces.
>
> Is my assumption/understanding consistent with the intent of the
> document? If so, some of the wording below should probably be
> changed. I.e., it would be good for the document to focus on the
> normal case usage.

The expected use of the protocol is for the RR (requesting router) to
request one delegation from the DR (delegating router).   This
sentence from the next-to-last paragraph in section 4 explains the
expected use:

   In a typical
   scenario based on the network shown in Figure 1, the requesting
   router subnets a single delegated /48 prefix into /64 prefixes and
   assigns one /64 prefix to each of the links in the subscriber
   network.

Is this sentence (which comes before the following paragraph in the
spec) sufficient?

> E.g.:
>
>>    Upon the receipt of a valid Reply message, for each IA_PD the
>>    requesting router assigns a subnet from each of the delegated
>>    prefixes to each of the links to which the associated interfaces are
>>    attached, with the following exception: the requesting router MUST
>>    NOT assign any delegated prefixes or subnets from the delegated
>>    prefix(es) to the link through which it received the DHCP message
>>    from the delegating router.
>
> do we need the above wording? I would expect that a CPE router with
> three interfaces will still only make one IA_PD request. Maybe this
> needs more discussion, i.e., as background.

in the typical scenario, i.e ISP delegating prefixes to a customer
only one IA_PD should be used.

to allow for some flexibility e.g if DHCPv6 PD should be used within
an administrative domain we allow for multiple IA_PDs. this is also
consistent with the way IA_NA's work.

> Nits:
>
>>    for delegating long-lived prefix from a delegating router to a
>
> s/long-lived/a long-lived/

fixed.

>>    This document describes new options for DHCP, which provide a
>>    mechanism for the delegation of IPv6 prefixes.  Through these
>
> s/which/that/

s/, which/that/

>>    This document describes an extension to the DHCPv6 specification [6].
>
> I hope this option isn't "extending" the dhcpv6 spec. In general,
> options don't do that, they are just opaque blobs carried by DHC. Or
> is this one different?

changed to "This document describes new DHCPv6 options for IPv6 prefix
delegation"

>>                        IA_PD has an associated IAID.  A requesting
>
> IAID used without definition/expansion.

defined in the DHCPv6 specification.

>>    If the delegating router cannot delegate any prefixes to an IA_PD in
>>    the message from the requesting router, the delegating router MUST
>>    include the IA_PD in the Advertise message with no prefixes in the
>>    IA_PD and a Status Code option in the IA_PD containing status code
>>    NoPrefixAvail.
>
> Is this error going to be useful enough in terms of figuring  out why
> the request was denied? E.g, authorization failed?

consistent with address assignment. any reason why we would need more
error codes for PD and the same reasoning wouldn't apply to addresses?
don't think so?

>>    If the delegating router will not assign any prefixes to any IA_PDs
>>    in a subsequent Request from the requesting router, the delegating
>>    router MUST send an Advertise message to the requesting router that
>>    includes a Status Code option with code NoPrefixAvail and a status
>>    message for the user, a Server Identifier option with the delegating
>>    router's DUID and a Client Identifier option with the requesting
>>    router's DUID.
>
> This seems like a more detailed repetition  of an earlier paragraph:
>
>    If the delegating router cannot delegate any prefixes to an IA_PD in
>    the message from the requesting router, the delegating router MUST
>    include the IA_PD in the Advertise message with no prefixes in the
>    IA_PD and a Status Code option in the IA_PD containing status code
>    NoPrefixAvail.
>
> Are both really needed?

otherwise the requesting router cannot know which IA_PD failed.  However,
it does seem like the Status Code option in the first paragraph (which
would not be contained in an IA_PD) is superfluous.  We will combine
the two paragraphs and eliminate the Status Code option from the first
paragraph.

>>    messages sent by the requesting router.  The IA_PD option include all
>
> s/include/includes/

fixed.

>>    When a requesting router subnets a delegated prefix, it must assign
>>    additional bits to the prefix to generate unique, longer prefixes.
>>    For example, if the requesting router in Figure 1 were delegated
>>    3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and
>>    3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber
>>    network.  If the requesting router were delegated 3FFE:FFFF:0::/48
>>    and 3FFE:FFFF:1::/48, it might assign 3FFE:FFFF:0:1::/64 and
>>    3FFE:FFFF:1:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and
>>    3FFE:FFFF:1:2::/64 for assignment to the other link.
>
> Is this needed? I'm skeptical about the two (separate) delegations per
> above. Besides, wouldn't the ISP just delegate 3FF3:FFFF::/47?

The intent here is to illustrate the delegation of two independent prefixes.
The RR then assigns a /64 from each prefix to each interface.  Just
delegating a /47 would cause only one prefix to be assigned to each
interface.

In the following paragraph, I changed the example delegated prefixes
so they do not both come from the same /47.  Is this clearer?

   When a requesting router subnets a delegated prefix, it must assign
   additional bits to the prefix to generate unique, longer prefixes.
   For example, if the requesting router in Figure 1 were delegated
   3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and
   3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber
   network.  If the requesting router were delegated 3FFE:FFFF:0::/48
   and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and
   3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and
   3FFE:FFFF:5:2::/64 for assignment to the other link.

>>    If the requesting router assigns a delegated prefix to a link to
>>    which the router is attached, and begins to send router
>>    advertisements for the prefix on the link, the requesting router MUST
>>    set the valid lifetime in those advertisements to be no later than
>>    the valid lifetime specified in the IA_PD Prefix option.  A
>>    requesting router MAY use the preferred lifetime specified in the
>>    IA_PD Prefix option.
>
> I wonder of more discussion about  lifetimes would be appropriate.

Can you be more explicit?  What part of the paragraph needs further
explanation?

> What happens if CPE router reboots and presents a different DUID?
> delegating router will reject that (in contrast to normal DHC). Will
> the right thing happen?

a CPE must keep its DUID according to DHCPv6 spec. what happens if the
DUID changes is dependent on delegating router policy. e.g a new
prefix could be delegated.

>>   An intruder requesting router may be able to mount a denial of
>
> What is "intruder requesting router"?

How about "malicious requesting router"?

>>    Because a requesting router and delegating routers must each have at
>>    least one assigned IPv6 address, the routers may be able to use IPsec
>>    for authentication of DHCPv6 messages.  The details of using IPsec
>>    for DHCPv6 are under development.
>
> Where in the spec is this made a requirement? The mention in the
> security considerations is the first reference to this I recall
> seeing.

The sentence you quoted is part of a paragraph in
the "Security Considerations" section:

   To guard against attacks through prefix delegation, requesting
   routers and delegating routers SHOULD use DHCP authentication as
   described in section "Authentication of DHCP messages" in the DHCP
   specification [6]. For point to point links, where one trusts that
   there is no man in the middle, or one trusts layer two
   authentication, DHCP authentication or IPsec may not be
   necessary. Because a requesting router and delegating routers must
   each have at least one assigned IPv6 address, the routers may be
   able to use IPsec for authentication of DHCPv6 messages. The
   details of using IPsec for DHCPv6 are under development.

We don't understand your question.  Why would this security
consideration be mentioned in an earlier section of the draft? 
What is the "this" in "...the first reference to this..."
referring to?

>
> Have someone familiar with Radius review section 5.1, especially the
> explicit radius example.

Use of AAA (RADIUS) is not key to the definition of this option.  We will
rewrite the example to use a more generic description of the assignment
of prefixes to a customer for delegation by the DR.

- Ole and Ralph 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg