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

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

On Mon, August 10, 2015 1:37 am, [e-mail] wrote:
> 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
>>
[snip]
> 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?

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

  thanks,

  Dan.