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" <[email protected]> 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:[email protected]] >> Sent: Monday, October 22, 2012 3:48 PM >> To: Black, David; Maglione Roberta; 'draft-ietf-softwire-dslite- >> [email protected]' >> Cc: Ralph Droms; [email protected]; [email protected] >> 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" <[email protected]> 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:[email protected]] >> >> Sent: Thursday, October 18, 2012 3:18 AM >> >> To: Black, David; Lee, Yiu; 'draft-ietf-softwire-dslite- >> >> [email protected]' >> >> Cc: Ralph Droms; [email protected]; [email protected] >> >> 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:[email protected]] >> >> Sent: Thursday, October 18, 2012 3:12 AM >> >> To: Lee, Yiu; Maglione Roberta; [email protected]; >> >> [email protected]; [email protected]; >> >>[email protected] >> >> Cc: [email protected]; [email protected]; 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:[email protected]] >> >> > Sent: Wednesday, October 17, 2012 8:46 PM >> >> > To: Black, David; [email protected]; >> >>[email protected]; >> >> > [email protected]; [email protected]; gen- >> >> [email protected] >> >> > Cc: [email protected]; [email protected]; 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" <[email protected]> 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 >> >> > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >> >> > >[email protected] Mobile: +1 (978) 394-7754 >> >> > >---------------------------------------------------- >> >> > > >> >> > > >> >> >> >> 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. >> >> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
