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

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

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.
>> 
>