Re: [secdir] secdir review of draft-vinapamula-softwire-dslite-prefix-binding-07

[<[e-mail]>]

Hi Dan, all, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dan Harkins [mailto:[e-mail]]
> Envoyé : samedi 8 août 2015 00:33
> À : Daniel Kahn Gillmor
> Cc : [e-mail]; [e-mail]; draft-vinapamula-softwire-dslite-
> [e-mail]
> Objet : Re: [secdir] secdir review of draft-vinapamula-softwire-dslite-
> prefix-binding-07
> 
> 
> On Fri, August 7, 2015 10:08 am, Daniel Kahn Gillmor wrote:
> > On Fri 2015-08-07 12:13:30 -0400, Dan Harkins wrote:
> >>   [ draft-vinapamula-softwire-dslite-prefix-binding-07 ]
> >
> >>   The main part of the solution is the introduction of a "Subscriber
> >> Mask" that allows a subscriber's CPE to be unambiguously identified
> >> when the mask is applied to a source IPv6 address. This identification
> >> allows for enforcement of per-subscriber policies even in the event of
> >> an address change.
> >>
> >>   The Security Considerations are sparse but address a potential
> >> DOS issue with a misbehaving user attempting to obtain additional
> >> resources by changing the address on its Basic Bridging Broadband
> >> element which seems to be the big issue here. All the other
> >> Security Considerations of DS-Lite apply and it refers to RFC 6333.
> >
> > I'm a bit puzzled by this document.  The Introduction says:
> >
> >    Note that in some deployments, CPE renumbering may be required to
> >    accommodate some privacy-related requirements to avoid assigning the
> >    same prefix to the same customer.  It is out of scope of this
> >    document to discuss such contexts.
> >
> > And then there is no mention of this concern ever again.  There is no
> > Privacy Considerations section (though the Security Considerations
> > section does mention one privacy consideration unrelated to the concern
> > raised in the Introduction).
> 
>   That's a very interesting point. The way I read it was that
> this draft deals with the impact of renumbering and not the reason
> why renumbering happened, so I didn't comment about it.

[Med] That's exactly the point.

> 
> > Is it acceptable to simply declare privacy considerations out-of-scope
> > for an I-D?  What are the "privacy-related requirements to avoid
> > assigning the same prefix to the same customer"?  in what deployments
> > should they be considered?
> >
> > https://tools.ietf.org/html/rfc6973 says:
> >
> >    The guidance provided here can and should be used to assess the
> >    privacy considerations of protocol, architectural, and operational
> >    specifications and to decide whether those considerations are to be
> >    documented in a stand-alone section, within the security
> >    considerations section, or throughout the document.
> >
> > Why are we considering these concerns (as important today as ever) "out
> > of scope" for the draft-vinapamula-softwire-dslite-prefix-binding?  How
> > is a potential deployer of this situation supposed to know whether their
> > context is one of the contexts where they should avoid this draft?
> >
> > To be clear: i'm not asking that the draft indicate how someone in one
> > of these privacy-sensitive contexts should approach enforcement of
> > per-subscriber policies.  But shouldn't the draft help a potential
> > deployer to decide whether they are in a context where they should or
> > should not apply the proposed standard?
> 
>   I thought a potential deployer should apply the proposed standard
> if they foresaw renumbering happening regardless of the reason. But
> your quote of RFC 6973 does seem to imply that if there are privacy
> considerations surrounding the use of the protocol (and privacy is
> obviously a reason for renumbering) then a stand alone section
> would be appropriate.
> 
>   Come to think of it, if the "Subscriber Mask" can be used to
> unambiguously identify a subscriber across renumbering then there
> is obviously a privacy consideration. Namely, if you are renumbering
> for privacy reasons, this protocol may mitigate the privacy effects
> of renumbering.

[Med] The mask does not allow to identify a CPE across renumbering (even within a DS-lite domain).

> 
>   Thank you for bringing this up! Let me retract my statement that
> this document is Ready. I will now say it is Almost Ready with the
> comment being that a Privacy Considerations section must be added
> to address the impact this protocol can have if the reason for
> renumbering was for privacy reasons.

[Med] There is already this text in the Security section:

   Also, the recommendations in Section 4 ensure the traffic is
   forwarded to a legitimate CPE.  If those recommendations are not
   implemented, privacy concerns may arise (e.g., If an IPv6 prefix is
   reassigned while mapping entries associated with that prefix are
   still active in the AFTR, sensitive data that belong to a previous
   prefix owner may be disclosed to the new prefix owner).

I have no problem to add a privacy section. What about the following change:

OLD:

5. Security Considerations

   Security considerations related to DS-Lite are discussed in
   [RFC6333].

   Enforcing the recommendations documented in Section 4 together with
   rate limiting softwires with new source IPv6 addresses from the same
   prefix defend against DoS attacks that would result in varying the
   B4's IPv6 address to exhaust AFTR resources.  A misbehaving CPE can
   be blacklisted by enforcing appropriate policies based on the prefix
   derived from the subscriber-mask.

   Also, the recommendations in Section 4 ensure the traffic is
   forwarded to a legitimate CPE.  If those recommendations are not
   implemented, privacy concerns may arise (e.g., If an IPv6 prefix is
   reassigned while mapping entries associated with that prefix are
   still active in the AFTR, sensitive data that belong to a previous
   prefix owner may be disclosed to the new prefix owner).

NEW:

5.  Security Considerations

   Security considerations related to DS-Lite are discussed in
   [RFC6333].

   Enforcing the recommendations documented in Section 4 together with
   rate limiting softwires with new source IPv6 addresses from the same
   prefix defend against DoS attacks that would result in varying the
   B4's IPv6 address to exhaust AFTR resources.  A misbehaving CPE can
   be blacklisted by enforcing appropriate policies based on the prefix
   derived from the subscriber-mask.

6.  Privacy Considerations

   A CPE connected to a DS-Lite network is identified by a set of
   information that is specific to each network domain (e.g., service
   credentials, device identifiers, etc.).  This document does not make
   any assumption nor introduce new requirements on how such
   identification is implemented network-wide.

   This document adheres to Sections 6 and 8 of [RFC6333] for handling
   IPv4-in-IPv6 packets and IPv4 translation operations.  In particular, this
   document does not leak extra information in packets exiting a DS-Lite
   network domain.

   The recommendations in Section 4 (bullet 6, in particular) ensure the
   traffic is forwarded to a legitimate CPE.  If those recommendations
   are not implemented, privacy concerns may arise (e.g., If an IPv6
   prefix is reassigned while mapping entries associated with that
   prefix are still active in the AFTR, sensitive data that belong to a
   previous prefix owner may be disclosed to the new prefix owner).

   These recommendations do not interfere with privacy extensions for
   generating IPv6 addresses (e.g., [RFC7217] or [RFC4941]).  These
   recommendations allow a CPE to generate new IPv6 addresses with
   privacy extensions without experiencing DS-Lite service degradation.

   This document does not nullify the privacy effects of non-stable IPv6
   prefixes.  Concretely, the subscriber-mask does not allow to identify
   a CPE across renumbering (even within a DS-Lite network domain).
   This document mitigates some of the undesired effects of reassigning
   an IPv6 prefix to another CPE (e.g., update a rendezvous service,
   remove stale mappings).

Better?

> 
>   Thanks again,
> 
>   Dan.
> 
>