Gen-ART review of draft-ietf-softwire-dslite-deployment-07

["Black, David" <[e-mail]>]

Authors,

The -07 version of this draft has resolved most of the concerns raised by
the  Gen-ART review of the -06 version of this draft, with one significant
exception:

> [5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that
> "the AFTR does not have detailed customer identity information."  Does
> that create a theft of service possibility?  If so, that possibility
> should be mentioned as a security consideration.  Also, Section 2.8
> ought to be expanded with a sentence or two explaining why the AFTR
> does not have that identity information, and in particular to explain
> whether and why it is unreasonable in some or all cases to expect
> that customer identity information be provided to the AFTR as part
> of provisioning each customer's softwire.

This has been partially resolved - the explanation of why the AFTR may
not have that identity information has been added.  Here's the text from
the -07 draft.

   Alternatively, AFTR may perform accounting for IPv4 traffic.
   However, operators must be aware that this will introduce some
   challenges especially in DSL deployment.  In DSL deployment, the AAA
   transaction normally happens between the edge router (i.e., Broadband
   Network Gateway) and AAA server.  [RFC6333] does not require the AFTR
   to interact with the AAA server or edge router.  Thus, AFTR may not
   have the AAA parameters (e.g., Account Session ID) associated to
   users to generate IPv4 accounting record.  The accounting process at
   the AFTR is only necessary if the operator requires separating per
   user accounting records for IPv4 and IPv6 traffic.  If the per user
   IPv6 accounting records, collected by the edge router, are
   sufficient, and the additional complexity of enabling IPv4 accounting
   at the ATFR is not required.  It is important to notice that, since
   the IPv4 traffic is encapsulated in IPv6 packets, the data collected
   by the edge router for IPv6 traffic already contain the total amount
   of traffic (i.e.  IPv4 and IPv6).

This revised text removes my concern about a security risk, but 
I think the result still provides more support than it should for
trying to do accounting without all the information needed to do it.

Please insert a sentence before "The accounting process at the AFTR is
only necessary if ..." to state that IPv4 traffic accounting at the AFTR
is not recommended when the necessary AAA parameters are not available.
The following sentence would suffice.

   IPv4 traffic accounting at the AFTR is not recommended when the
   AAA parameters necessary to generate complete IPv4 accounting
   records are not available.

Also, the response to this nit could be improved:

> Section 3.2.2 uses 192.0.0.2/32 as an example IP address for the
> B4.  That section should also cross-reference Section 5.7 on RFC 6333
> on IP address assignment to B4s, as other IP addresses may be used.

My original comment wasn't complete - here's a suggested text change
that should be clearer:

OLD
   Operators should assign the same IPv4 address
   (i.e., 192.0.0.2/32) to all AFTRs.  IANA allocates 192.0.0.0/29
   [RFC6333] Section 5.7 that can be used for this purpose.
NEW
   Operators should assign the same IPv4 address
   (e.g., 192.0.0.2/32 [RFC6333]) to all AFTRs.  IANA has allocated
   the 192.0.0.0/29 network prefix to provide IPv4 addresses for this
   purpose [RFC 6333].
END

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Monday, October 15, 2012 7:10 PM
> To: [e-mail]; [e-mail]; carlw@mcsr-
> labs.org; [e-mail]; [e-mail]; gen-
> [e-mail]
> Cc: [e-mail]; Black, David; [e-mail]; Ralph Droms
> Subject: Gen-ART review of draft-ietf-softwire-dslite-deployment-06
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-softwire-dslite-deployment-06
> Reviewer: David L. Black
> Review Date: October 15, 2012
> IETF LC End Date: October 16, 2012
> IESG Telechat Date: October 25, 2012
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> This is a generally well-written draft that expands considerably on the brief
> deployment considerations for DS-Lite in Appendix A of RFC 6333.  The draft
> is clear and reasonably well-written, and a significant improvement on that
> RFC 6333 Appendix, although an understanding of RFC 6333 is necessary to
> understand this draft, which seems completely reasonable.
> 
> The B4 and AFTR acronyms are clever - kudos to whomever came up with those.
> 
> I found five open issues, all of which are minor.
> 
> Minor Issues:
> 
> [1] Ironically, the first issue is that something should be said about
> the relationship of this draft to Appendix A of RFC 6333.  It probably
> suffices to say that this draft expands on the material in that Appendix,
> as I see no need to specify that this draft updates RFC 6333 solely to
> change non-normative material in an Appendix.
> 
> [2] The MTU increase technique in Section 2.2 is a "may", which is
> consistent with Section 5.3 of RFC 6333.  OTOH, Section 2.2 of this
> draft should also discuss the AFTR resource exhaustion concern that
> described in Section 6.3 of RFC 6333, as that is a potential
> operational reason for an ISP to increase MTU size (e.g., if customer
> sourcing of large IPv4 packets is not sufficiently rare).
> 
> [3] Section 2.7 refers to "the AFTR's internal interface".  There may be
> two internal interfaces, the physical IPv6 interface (outer header) and
> the tunnel's IPv4 interface (inner header).  The text should be clarified
> to indicate which interface is involved - it appears that the AFTR's
> physical IPv6 interface is intended in this section.
> 
> [4] Section 2.7 cites RFC 6333 for use of DHCPv6 with DS-Lite.  RFC 6334
> should be cited - either in addition to or instead of RFC 6333.
> 
> [5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that
> "the AFTR does not have detailed customer identity information."  Does
> that create a theft of service possibility?  If so, that possibility
> should be mentioned as a security consideration.  Also, Section 2.8
> ought to be expanded with a sentence or two explaining why the AFTR
> does not have that identity information, and in particular to explain
> whether and why it is unreasonable in some or all cases to expect
> that customer identity information be provided to the AFTR as part
> of provisioning each customer's softwire.
> 
> Nits:
> 
> Section 2.3 on MTU Considerations could usefully mention MTU discovery
> techniques, as possibilities for customer IPv4 traffic to adapt to a
> smaller IPv4 MTU.  If this is done, it would be useful to mention
> RFC 4821 in addition to the mention of RFC 1191 in RFC 6333.
> 
> Section 2.4 should define "lawful intercept".  It would be helpful to
> cite a reference for this concept if something appropriate can be found.
> 
> Section 2.5:
> - Are one or both types of logging recommended?
> - Last paragraph on p.4, "timestamped log" is not a good verb phrase.
> 	"maintain a timestamped log of" would be a better replacement.
> - Last paragraph in section, where is the batch file sent?
> 
> In Section 2.7, I'm having a hard time understanding which traffic is
> intended to be subject to the Outgoing Policies and the Incoming Policies.
> Expanding each of those two bullets to explain what traffic is subject
> to each class of policies would help.
> 
> Section 3.2.2.2 uses 192.0.0.2/32 as an example IP address for the
> B4.  That section should also cross-reference Section 5.7 on RFC 6333
> on IP address assignment to B4s, as other IP addresses may be used.
> 
> idnits 2.12.13 found a tiny nit - draft-ietf-pcp-base is now at
> version 28.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>