Last Call Review of draft-vinapamula-softwire-dslite-prefix-binding-07
review-vinapamula-softwire-dslite-prefix-binding-07-secdir-lc-harkins-2015-08-13-00

Request Review of draft-vinapamula-softwire-dslite-prefix-binding
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-08-18
Requested 2015-07-08
Draft last updated 2015-08-13
Completed reviews Genart Last Call review of -07 by Tom Taylor (diff)
Genart Last Call review of -09 by Tom Taylor (diff)
Secdir Last Call review of -07 by Dan Harkins (diff)

Assignments

Review
review-vinapamula-softwire-dslite-prefix-binding-07-secdir-lc-harkins-2015-08-13

  Hello,

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  This draft proposes several recommendations to handle the case
where a Basic Bridging Broadband element in a DS-Lite deployment
gets a new IPv6 address. Such a change can have problems associated
with address-specific policy enforcement, subscriber resource
tracking, as well as loss of packets going to the previous address
and the recommendations are designed to minimize and mitigate those
problems.

  The main part of the solution is the introduction of a "Subscriber
Mask" that allows a subscriber's CPE to be unambiguously identified
when the mask is applied to a source IPv6 address. This identification
allows for enforcement of per-subscriber policies even in the event
of an address change.

  The Security Considerations are sparse but address a potential
DOS issue with a misbehaving user attempting to obtain additional
resources by changing the address on its Basic Bridging Broadband
element which seems to be the big issue here. All the other
Security Considerations of DS-Lite apply and it refers to RFC 6333.

  I consider the document Ready.

  regards,

  Dan.