Requirements for IPv6 Prefix Delegation
draft-ietf-ipv6-prefix-delegation-requirement-04

[Ballot comment]
My original comment was: please explain "secure transmission" in section 3.5.
 
  It looks like section 3.5 has been renumbered, and it is now section 3.6.
  The section now talks about authentication, which is good.  I believe that
  integrity protection is necessary.  I am not sure if confidentiality is
  also needed.

[Ballot comment]
The security terminology could be a bit clearer, but I'm not going to worry.  That said, if the document goes back for any more work, I'll supply some new text.

My original comment was: please explain "secure transmission" in section 3.5.  It looks like section 3.5 has been renumberd, and it is now section 3.6.  The section now talks about authentication, which is good.  I believe that integrity protection is necessary.  I am not sure if confidentiality is also needed.

[Note]: '2004-03-23: This document should be approved now. A revised ID was needed to deal with comments originally from Randy. This document is back on the agenda only because it''s an "old-style" ballot, so there is no formal record that the IESG signed off on the document, modulo Randy''s comments. Please, no new review of this document; it just needs to be approved.' added by Thomas Narten

3.1 Number and Length of Delegated Prefixes

  The prefix delegation mechanism should allow for delegation of
  prefixes of lengths between /48 and /64, inclusively.  Other lengths
  may be supported. The mechanism should allow for delegation of more
  than one prefix to the customer.

should it not provide for allocation of lengths less than /48?

---

3.4 Policy-based Assignment

  The prefix delegation mechanism should allow for the use of policy in
  assigning prefixes to a customer.  For example, the customer's
  identity and type of subscribed service may be used to determine the
  address block from which the customer's prefix is selected, and the
  length of the prefix assigned to the customer.

is this not really a function further back in the isp?  note that
the document's goals are

  The delegation mechanism will be intended to automate the
  process of informing the customer's networking equipment of the
  prefixes to be used at the customer's site.

---

3.5 Security and Authentication

  The prefix delegation mechanism must provide for reliable
  authentication of the identity of the customer to which the prefixes
  are to be assigned, and must provide for reliable, secure
  transmission of the delegated prefixes to the customer.

and should the customer not be able to authenticate the delegator
e.g., to prevent being given bad address space on a multi-isp
medium?  it seems that they know this issue, as the sec cons says

  A rogue delegating router can issue bogus prefixes to a requesting
  router.  This may cause denial of service due to unreachability.

---

3.6 Accounting

  The prefix delegation mechanism must allow for the ISP to provide
  accounting information about delegated prefixes.

is this not really a function further back in the isp?  note that
the document's goals are

  The delegation mechanism will be intended to automate the
  process of informing the customer's networking equipment of the
  prefixes to be used at the customer's site.

---

3.7 Hardware technology Considerations

  The prefix delegation mechanism should work on any hardware
  technology

perhaps it should be scoped to PE/CPE equipment?

---

5. Security considerations
...
  A rogue requesting router (CPE) may be able to mount a denial of
  service attack by repeated requests for delegated prefixes that
  exhaust the delegating router's available prefixes.

this is the first hint that the model includes request as well as
push.  if this is really intended, and i am not hard against it,
then sec cons should mandate authentication of the request. 

and probably request semantics should be discussed above, e.g.,
length of request, preference for expanding existing delegation(s),
etc.

-30-