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

[<[e-mail]>]

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:[e-mail]] 
Sent: Donnerstag, 23. Oktober 2014 23:12
To: [e-mail]
Cc: [e-mail]; [e-mail]
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:

    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.

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