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

From: Samuel Weiler <[email-masked]>
Date: Thu, 23 Oct 2014 17:11:53 -0400 (EDT)

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.

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.

I would like to see a discussion of provisioning mechanism security.
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?

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.

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

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

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.

---

From: <[email-masked]>
Date: Mon, 27 Oct 2014 06:50:19 +0000

Dear Samuel,

Meany thank for the review.

Please see inline.

Cheers,
Med

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

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

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

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

[Med] No IMHO.

Non-security stuff:

[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 

[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:

[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])."

[Med] What about:

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

---

From: <[email-masked]>
Date: Thu, 30 Oct 2014 12:23:13 +0100

Hi Samuel,

Thanks for your review. Regarding the DISCUSSs that you've raised, I've suggested some additional text that could be added in each case. Please let me know what you think.

Cheers,
Ian

-----Original Message-----
From: Samuel Weiler [mailto:[email-masked]] 
Sent: Donnerstag, 23. Oktober 2014 23:12
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: 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.

[if] What about adding the following text to Sec 5.1:

On receipt of such and ICMP error message, the lwB4 MUST validate the source address to be the same as the lwAFTR address which is configured. In the event that these addresses do not match, the lwAFTR MUST discard the ICMP error message.

In order to prevent forged ICMP messages using the spoofed lwAFTR address as the source being sent to lwB4s, the operator can implement network ingress filtering as described in [RFC2827].
----
It's probably worth explaining this 2119 RECOMMENDation in more
detail:

[if] We could extend this with the following sentence:

Section 5.2.2 of [RFC6269] provides analysis of allocating well-known ports to clients with IPv4 address sharing.
------
I would like to see a discussion of provisioning mechanism security.
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?

[if] The following could be added to Sec 9 (Security Considerations):

This document describes a number of different protocols which may be used for the provisioning of lw4o6. In each case, the security considerations relevant to the provisioning protocol are also relevant to the provisioning of lw4o6 using that protocol. lw4o6 does not add any additional provisioning protocol specific security considerations.
------

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.

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

[if] Propose the following wording to be added after the paragraph starting ³An lwB4 MUST support dynamic port-restricted IPv4 address provisioning²:

Provisioning of the lwB4 using DHCPv6 as described here allocates a single PSID to the client. In the event that the client is concurrently using all of the provisioned L4 ports it may be unable to initiate any additional outbound connections. DHCPv6 based provisioning does not provide a mechanism for the client to request more L4 ports. Other provisioning mechanisms (e.g. PCP based
provisioning)
provide this function.

Issues relevant to IP address sharing are discussed in more detail in [RFC6269].

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 08:46:41 -0400

> Thanks for your review. Regarding the DISCUSSs that you've raised, I've suggested some additional text that could be added in each case. Please let me know what you think.

FYI, it's Kathleen who raised the DISCUSS, so you need to get her to agree to your proposed changes.  Getting Sam to agree is nice, but won't get the DISCUSS cleared... :)