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

["Dan Harkins" <[e-mail]>]

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.

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

  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.