Re: [secdir] secdir review of draft-ietf-softwire-lw4over6-11

[<[e-mail]>]

Dear Samuel,

Meany thank for the review.

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Samuel Weiler [mailto:[e-mail]] 
Envoyé : jeudi 23 octobre 2014 23:12
À : [e-mail]
Cc : [e-mail]; [e-mail]
Objet : secdir review of draft-ietf-softwire-lw4over6-11

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.


Does this mechanism introduce new points for a DoS attack,
e.g. forging the ICMPv6 error message (type 1, code 5) mentioned in
Section 5.1?  I would like to see a list and discussion of these or,
if appropriate, an analysis showing that none exist.

[Med] Good point. We can add this sentence: 

"lwAFTR MUST rate limit ICMPv6 error messages to defend against DoS attacks generated by an abuse user.".

It's probably worth explaining this 2119 RECOMMENDation in more 
detail:

    Unless an lwB4 is being allocated a full IPv4 address, it is
    RECOMMENDED that PSIDs containing the well-known ports (0-1023) are
    not allocated to lwB4s.

[Med] FWIW, this text was added as a response to a comment from the WG (http://www.ietf.org/mail-archive/web/softwires/current/msg06008.html,
https://www.ietf.org/mail-archive/web/softwires/current/msg06035.html). Saying that, I'm personally for removing this sentence from the draft. This is more deployment-specific rather than an architectural discussion. We can just remove this one and let any deployment draft discuss this point further. 

I would like to see a discussion of provisioning mechanism security.

[Med] This is out of scope of this document. Dedicated provisioning mechanism specification documents should discuss it. We can add a sentence to Section 9 to capture this.

Are there security-related factors that should drive the choice of
provisioning mechanism (the doc mentions several options...)?  Are
there configuration choices that should or must be made when using one
of thsoe for this purpose?

[Med] No IMHO.

Non-security stuff:

I'm not seeing any explicit discussion of whether (and how) a lwB4 can 
request additional port space after the initial assignment.  If that 
feature does not exist, I would like to see it explicitly acknowledged 
as a limitation with a discussion of why it is not being provided.

[Med] This is implementation-specific. This feature is supported when PCP is used for instance (draft-ietf-pcp-port-set).

Again, assuming that there is not such a mechanism: since this is the 
architecture document, I would like to see a few words on expected 
port assignment/utilization ratios.  

[Med] Discussion on address sharing ratio is deployment-specific. It has nothing to do with in an architectural document. You may find a discussion in http://tools.ietf.org/html/rfc6269#appendix-B and http://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05#section-4.2. 


Assuming a typical case of a 
residential subscriber, it seems that lw4o6 would need to assign 
enough ports to each user to accommodate expected peak usage.  This 
pretty clearly results in fewer users accommodated on a public v4 
address than if they were sharing the port space on demand.  How much 
much v4 space does lw4o6 consume in this environment compared to 
DS-Lite?

[Med] This is deployment-specific. Please refer to http://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05#section-4.2 

Editorial stuff:

The next-to-last paragraph of section 1 doesn't seem to flow well with
the text around it, perhaps for lack of clarity in pronoun
antecedents:

    This document is an extended case, which covers address sharing for
    [RFC7040].  It is also a variant of A+P called Binding Table Mode
    (see Section 4.4 of [RFC6346]).

[Med] What about:

    "This document extends the mechanism defined in [RFC7040] by allowing address sharing. The solution in this document is also a variant of A+P called Binding Table Mode (see Section 4.4 of [RFC6346])."


And I think something is broken in the below sentence:

    The solution specified in this document allows the assignment of
    either a full or a shared IPv4 address requesting CPEs.

[Med] What about:

   "This document allows for the assignment of
    either a full IPv4 address or a shared IPv4 address to requesting CPEs."