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

From: "Dan Harkins" <[email-masked]>
Date: Fri, 7 Aug 2015 09:13:30 -0700 (PDT)

Hello,

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  This draft proposes several recommendations to handle the case
where a Basic Bridging Broadband element in a DS-Lite deployment
gets a new IPv6 address. Such a change can have problems associated
with address-specific policy enforcement, subscriber resource
tracking, as well as loss of packets going to the previous address
and the recommendations are designed to minimize and mitigate those
problems.

  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 consider the document Ready.

  regards,

  Dan.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Aug 2015 13:08:02 -0400

On Fri 2015-08-07 12:13:30 -0400, Dan Harkins wrote:
>   [ draft-vinapamula-softwire-dslite-prefix-binding-07 ]

> allows for enforcement of per-subscriber policies even in the event of
> an address change.
>

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

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?

       --dkg

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 7 Aug 2015 15:32:55 -0700 (PDT)

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

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

  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.

  Thanks again,

  Dan.

---

From: <[email-masked]>
Date: Mon, 10 Aug 2015 08:37:03 +0000

Hi Dan, all, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Dan Harkins [mailto:[email-masked]]
> Envoyé : samedi 8 août 2015 00:33
> À : Daniel Kahn Gillmor
> Cc : [email-masked]; [email-masked]; draft-vinapamula-softwire-dslite-
> [email-masked]
> Objet : Re: [secdir] secdir review of draft-vinapamula-softwire-dslite-
> prefix-binding-07
> 
> 

[Med] That's exactly the point.

> for privacy reasons, this protocol may mitigate the privacy effects

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

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

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 11 Aug 2015 22:43:04 -0700 (PDT)

>> Objet : Re: [secdir] secdir review of draft-vinapamula-softwire-dslite-
[snip]
>    an IPv6 prefix to another CPE (e.g., update a rendezvous service,

  Yes! I like the mention of RFC 4941 too. That looks great.

  thanks,

  Dan.

---

From: <[email-masked]>
Date: Thu, 13 Aug 2015 08:50:04 +0000

Hi Dan,

Great!

A new version with the proposed changes is available online: https://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-prefix-binding/ 

A diff to track the changes is available at: https://www.ietf.org/rfcdiff?url2=draft-vinapamula-softwire-dslite-prefix-binding-09

Many thanks for the review. 

Cheers,
Med 

> Envoyé : mercredi 12 août 2015 07:43
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Daniel Kahn Gillmor; [email-masked]; [email-masked]; draft-
> [email-masked]
> Objet : RE: [secdir] secdir review of draft-vinapamula-softwire-dslite-
> prefix-binding-07
> 
> 
>