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

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

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