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

[<[e-mail]>]

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 

> -----Message d'origine-----
> De : Dan Harkins [mailto:[e-mail]]
> Envoyé : mercredi 12 août 2015 07:43
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Daniel Kahn Gillmor; [e-mail]; [e-mail]; draft-
> [e-mail]
> Objet : RE: [secdir] secdir review of draft-vinapamula-softwire-dslite-
> prefix-binding-07
> 
> 
> 
> 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.
>