Re: [Gen-art] Gen-ART review of draft-ietf-softwire-dslite-deployment-06

["Lee, Yiu" <[e-mail]>]

Hi David,

Got it. We will capture all these comments in the next revision.

Thanks again for reviewing the draft.

Yiu

On 10/22/12 4:45 PM, "Black, David" <[e-mail]> wrote:

>Hi Yiu,
>
>> Since the BNG would verify the v6 packets sent by B4 and the AFTR would
>> NAT the RFC1918 source address to the public address, I try to find a
>>use
>> case where a theft could steal the service.
>
>Important clarification - I did not originally assert that there is a
>theft of service possibility, rather I only asked whether there is one -
>"Does that create a theft of service possibility?".
>
>If the answer is "no", then an explanation of why that is the answer
>ought to suffice.  Here's the draft's text on this topic:
>
>   Alternatively, AFTR is a logical place to perform IPv4 accounting,
>   but it will potentially introduce some additional complexity because
>   the AFTR does not have detailed customer identity information.  The
>   accounting process at the AFTR is only necessary if the operator
>   requires separating per user accounting records for IPv4 and IPv6
>   traffic.
>
>Continuing:
>
>> From the AFTR's perspective,
>> the IPv4 address of the host behind B4 is irrelevant. Could you help to
>> find a use case which will introduce security risk because the AFTR
>>can't
>> identify the IPv4 address?
>
>In revising the draft, please also explain how "the operator requires
>separating per user accounting records for IPv4 and IPv6 traffic" is
>consistent with "the IPv4 address of the host behind the B4 is
>irrelevant".
>The answer probably starts with an explanation of the behavior of the
>NAT in the AFTR, although I note that section 2.13 of the draft describes
>a case in which the IPv4 address behind the B4 appears to be relevant
>(e.g., for an operator who charges differently for traffic inbound to
>a customer server by comparison to other customer traffic).
>
>Backing out of this level of detail, all I'm asking for is an explanation
>of why or under what circumstances the lack of identity information at
>the AFTR does not pose a security concern when usage accounting is done
>there and the assumptions on which that is based - e.g., it might be
>appropriate to say that the BNG should verify the v6 packets sent by B4.
>
>I'm not trying to be difficult.  In general, absence of identity
>information
>raises theft of service concerns in accounting systems, and if that's
>really
>not a problem in this case, I just want to see a solid explanation of why
>that's not a problem.
>
>Thanks,
>--David
>
>
>> -----Original Message-----
>> From: Lee, Yiu [mailto:[e-mail]]
>> Sent: Monday, October 22, 2012 3:48 PM
>> To: Black, David; Maglione Roberta; 'draft-ietf-softwire-dslite-
>> [e-mail]'
>> Cc: Ralph Droms; [e-mail]; [e-mail]
>> Subject: Re: Gen-ART review of draft-ietf-softwire-dslite-deployment-06
>>
>> Hi David,
>>
>> Since the BNG would verify the v6 packets sent by B4 and the AFTR would
>> NAT the RFC1918 source address to the public address, I try to find a
>>use
>> case where a theft could steal the service. From the AFTR's perspective,
>> the IPv4 address of the host behind B4 is irrelevant. Could you help to
>> find a use case which will introduce security risk because the AFTR
>>can't
>> identify the IPv4 address?
>>
>> Thanks,
>> Yiu
>>
>> On 10/18/12 11:10 AM, "Black, David" <[e-mail]> wrote:
>>
>> >Hello Roberta,
>> >
>> >In that case, more text is needed to explain in Section 2.8, and
>> >the related theft of service concern also needs to be discussed in
>> >that section and/or the Security Considerations section.
>> >
>> >Thanks,
>> >--David
>> >
>> >> -----Original Message-----
>> >> From: Maglione Roberta [mailto:[e-mail]]
>> >> Sent: Thursday, October 18, 2012 3:18 AM
>> >> To: Black, David; Lee, Yiu; 'draft-ietf-softwire-dslite-
>> >> [e-mail]'
>> >> Cc: Ralph Droms; [e-mail]; [e-mail]
>> >> Subject: RE: Gen-ART review of
>>draft-ietf-softwire-dslite-deployment-06
>> >>
>> >> Hello Yiu and David,
>> >> regarding point 5:
>> >>
>> >> > [YL] Good catch. Actually I believe AFTR "does" have both IPv4 and
>> >> > IPv6 to identify the customer. I suggest we remove
>> >> >
>> >> > "but it will potentially introduce some additional complexity
>>because
>> >> >    the AFTR does not have detailed customer identity information."
>> >>
>> >> The point related to the accounting is different: what I meant here
>>with
>> >> accounting is RADIUS based accounting, commonly used in Broadband
>>networks.
>> >>
>> >> Today RADIUS accounting is done at the BNG level, the problem with
>>the
>> >> introduction of the AFTR is that the AFTR does not interact with
>>AAA/RADIUS
>> >> Server for the initial authentication/authorization/accounting phase
>>because
>> >> the authentication/authorization/accounting process happens between
>>BNG and
>> >> RADIUS Server when the session comes up.
>> >> The ATFR is not able to perform RADIUS accounting because as it does
>>not
>> >> interact with the RADIUS Server it does not have " detailed customer
>>identity
>> >> information" for example it does know the accounting session ID
>>associated to
>> >> that session, that's why it cannot do detailed accounting for each
>>single
>> >> subscriber even if the ATFR can still correlated IPv6 and IPv4
>>traffic
>> >> belonging to the same user.
>> >>
>> >> This is an important operational issue, I would suggest to keep this
>>concept.
>> >> If you think is needed I can add some lines of text in order to
>>clarify this
>> >> point.
>> >>
>> >> Thanks
>> >> Regards,
>> >> Roberta
>> >>
>> >> -----Original Message-----
>> >> From: Black, David [mailto:[e-mail]]
>> >> Sent: Thursday, October 18, 2012 3:12 AM
>> >> To: Lee, Yiu; Maglione Roberta; [e-mail];
>> >> [e-mail]; [e-mail];
>> >>[e-mail]
>> >> Cc: [e-mail]; [e-mail]; Ralph Droms; Black, David
>> >> Subject: RE: Gen-ART review of
>>draft-ietf-softwire-dslite-deployment-06
>> >>
>> >> Yiu,
>> >>
>> >> Thank you for your responses - most of them look fine, and in
>> >> particular anything that I don't comment on here is acceptable to me.
>> >>
>> >> > [YL] In 2.2, we will add:
>> >> >
>> >> > "Note that reassembly at Tunnel Exit-Point is resource
>> >> >       intensive. A large number of B4 may terminate on the same
>>AFTR. If many B4
>> >> >       fragment the packets, it would increase sufficient load to
>>the AFTR for
>> >> >       reassembly. We recommend the operator should increase the
>>MTU size of the IPv6
>> >> >       network between B4 and AFTR to avoid fragmentation."
>> >>
>> >> I would change "is" to "may be" in the first line.
>> >>
>> >> > >[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.
>> >> >
>> >> > [YL] Good catch. Actually I believe AFTR "does" have both IPv4 and
>> >>IPv6 to
>> >> > identify the customer. I suggest we remove
>> >> >
>> >> > "but it will potentially introduce some additional complexity
>>because
>> >> >    the AFTR does not have detailed customer identity information."
>> >>
>> >> That's definitely an easy way to address that issue, and it's fine
>>with
>> >>me.
>> >>
>> >> > >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.
>> >> >
>> >> > [YL] We would consider RFC 4821. However, the challenge is I don't
>> >>have
>> >> > information how many current OS support RFC 4821. Since DS-lite is
>>a
>> >> > transition technology, it would be unreasonable to ask the OS
>>company
>> >>to
>> >> > implement RFC 4821 for DS-lite.
>> >>
>> >> That's ok - this was a nit.
>> >>
>> >> > >- Are one or both types of logging recommended?
>> >> >
>> >> > [YL] We tempted to recommend source-specific log. However, some
>> >>regulators
>> >> > require to use both and the regulations vary country from country,
>> >>this is
>> >> > why we left it open and let the operators to decide.
>> >>
>> >> Please add a version of your explanation to the draft.
>> >>
>> >> > >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.
>> >> >
>> >> > [YL] Does this help?
>> >> >
>> >> > Outgoing Policies apply to packets originating from B4 to IPv4
>> >>network.
>> >> > Incoming Policies apply to packets originating from IPv4 network to
>> >>B4.
>> >>
>> >> Yes, that's clearer, although the B4 is not the network endpoint for
>>any
>> >> of that traffic.  I suggest:
>> >>
>> >> Outgoing Policies apply to packets originating from behind the B4
>>with
>> >> a destination on the IPv4 network.
>> >>
>> >> Incoming Policies apply to packets originating from the IPv4 network
>>to
>> >> a destination behind the B4.
>> >>
>> >> Thanks,
>> >> --David
>> >>
>> >>
>> >> > -----Original Message-----
>> >> > From: Lee, Yiu [mailto:[e-mail]]
>> >> > Sent: Wednesday, October 17, 2012 8:46 PM
>> >> > To: Black, David; [e-mail];
>> >>[e-mail];
>> >> > [e-mail]; [e-mail]; gen-
>> >> [e-mail]
>> >> > Cc: [e-mail]; [e-mail]; Ralph Droms
>> >> > Subject: Re: Gen-ART review of
>> >>draft-ietf-softwire-dslite-deployment-06
>> >> >
>> >> > Hi David,
>> >> >
>> >> > Thanks very much for review the draft. Comments inline.
>> >> >
>> >> > Thanks,
>> >> > Yiu
>> >> >
>> >> > On 10/15/12 7:10 PM, "Black, David" <[e-mail]> wrote:
>> >> >
>> >> > >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.
>> >> >
>> >> > [YL] In "Overview", we will add:
>> >> >
>> >> > "This document expands Appendix A of RFC6333 and discusses various
>> >> > DS-Lite deployment considerations for operators."
>> >> >
>> >> > >
>> >> > >[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).
>> >> >
>> >> > [YL] In 2.2, we will add:
>> >> >
>> >> > "Note that reassembly at Tunnel Exit-Point is resource
>> >> >       intensive. A large number of B4 may terminate on the same
>>AFTR.
>> >>If
>> >> many B4
>> >> >       fragment the packets, it would increase sufficient load to
>>the
>> >>AFTR
>> >> for
>> >> >       reassembly. We recommend the operator should increase the MTU
>> >>size of
>> >> the IPv6
>> >> >       network between B4 and AFTR to avoid fragmentation."
>> >> >
>> >> > >
>> >> > >[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.
>> >> >
>> >> > [YL] We replace "internal" to "IPv6"
>> >> >
>> >> > >
>> >> > >[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.
>> >> >
>> >> > [YL] Fixed
>> >> >
>> >> > >
>> >> > >[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.
>> >> >
>> >> > [YL] Good catch. Actually I believe AFTR "does" have both IPv4 and
>> >>IPv6 to
>> >> > identify the customer. I suggest we remove
>> >> >
>> >> > "but it will potentially introduce some additional complexity
>>because
>> >> >    the AFTR does not have detailed customer identity information."
>> >> >
>> >> > >
>> >> > >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.
>> >> >
>> >> > [YL] We would consider RFC 4821. However, the challenge is I don't
>> >>have
>> >> > information how many current OS support RFC 4821. Since DS-lite is
>>a
>> >> > transition technology, it would be unreasonable to ask the OS
>>company
>> >>to
>> >> > implement RFC 4821 for DS-lite.
>> >> >
>> >> > >
>> >> > >Section 2.4 should define "lawful intercept".  It would be
>>helpful to
>> >> > >cite a reference for this concept if something appropriate can be
>> >>found.
>> >> >
>> >> > [YL] We will find whether there is any reference to this concept.
>>If
>> >>we
>> >> > can't find any, we would add an explanation in the draft.
>> >> >
>> >> > >
>> >> > >Section 2.5:
>> >> > >- Are one or both types of logging recommended?
>> >> >
>> >> > [YL] We tempted to recommend source-specific log. However, some
>> >>regulators
>> >> > require to use both and the regulations vary country from country,
>> >>this is
>> >> > why we left it open and let the operators to decide.
>> >> >
>> >> > >- Last paragraph on p.4, "timestamped log" is not a good verb
>>phrase.
>> >> > >     "maintain a timestamped log of" would be a better
>>replacement.
>> >> >
>> >> > [YL] Fixed
>> >> >
>> >> > >- Last paragraph in section, where is the batch file sent?
>> >> >
>> >> > [YL] We will add:
>> >> >
>> >> > "The files may be compressed before transferring to a repository
>> >>server
>> >> >       to better utilize bandwidth and storage."
>> >> >
>> >> >
>> >> > >
>> >> > >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.
>> >> >
>> >> > [YL] Does this help?
>> >> >
>> >> > Outgoing Policies apply to packets originating from B4 to IPv4
>> >>network.
>> >> > Incoming Policies apply to packets originating from IPv4 network to
>> >>B4.
>> >> >
>> >> >
>> >> >
>> >> > >
>> >> > >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.
>> >> >
>> >> > [YL] Added the cite.
>> >> >
>> >> > >
>> >> > >idnits 2.12.13 found a tiny nit - draft-ietf-pcp-base is now at
>> >> > >version 28.
>> >> >
>> >> > [YL] Fixed.
>> >> >
>> >> > >
>> >> > >Thanks,
>> >> > >--David
>> >> > >----------------------------------------------------
>> >> > >David L. Black, Distinguished Engineer
>> >> > >EMC Corporation, 176 South St., Hopkinton, MA  01748
>> >> > >[phone]             FAX: [phone]
>> >> > >[e-mail]        Mobile: [phone]
>> >> > >----------------------------------------------------
>> >> > >
>> >> > >
>> >>
>> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
>>alle
>> >> persone indicate. La diffusione, copia o qualsiasi altra azione
>> >>derivante
>> >> dalla conoscenza di queste informazioni sono rigorosamente vietate.
>> >>Qualora
>> >> abbiate ricevuto questo documento per errore siete cortesemente
>>pregati
>> >>di
>> >> darne immediata comunicazione al mittente e di provvedere alla sua
>> >> distruzione, Grazie.
>> >>
>> >> This e-mail and any attachments is confidential and may contain
>> >>privileged
>> >> information intended for the addressee(s) only. Dissemination,
>>copying,
>> >> printing or use by anybody else is unauthorised. If you are not the
>> >>intended
>> >> recipient, please delete this message and any attachments and advise
>>the
>> >> sender by return e-mail, Thanks.
>> >>
>> >