Re: [secdir] secdir review of draft-ietf-radext-ip-port-radius-ext-10

[<[e-mail]>]

Dear Carl, 

(Apologies for the delay to answer this message).

Thank you very much for the review.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Carl Wallace [mailto:[e-mail]]
> Envoyé : lundi 15 août 2016 21:56
> À : [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : secdir review of draft-ietf-radext-ip-port-radius-ext-10
> 
> 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.
> 
> This document defines three new RADIUS attributes.  For devices that
> implement IP port ranges, these attributes are used to communicate with a
> RADIUS server in order to configure and report TCP/UDP ports and ICMP
> identifiers, as well as mapping behavior for specific hosts.
> 
> 
> I've a few questions/comments:
> 
> - The Security Considerations section currently references the security
> considerations from 2865 and 5176.  Should 6887 be included to address
> considerations related to the forwarding attribute?

[Med] Referring to the PCP security considerations may not be justified here given that the RADIUS client and server are in the same trust domain. We have this text in the draft for this point:

   This document targets deployed where a trusted relationship is in
   place between the RADIUS client and server with communication
   optionally secured by IPsec or Transport Layer Security (TLS)
   [RFC6614].

> - When the port limit attribute is used, does presentation of a new
> "global" setting undo previously established IP specific settings (or vice
> versa)?

[Med] I'm not sure to understand the question here. But, 
* if the question is whether the new limit replaces the one, the answer is yes. 
* if the question is how the new limit is applied if alive sessions for a given subscriber exceed the new limit, the answer is this is implementation-specific. A CGN has to deal with that any way (see this REQ from RFC6888). We defer to the implementation behavior. 

===

   REQ-4:  A CGN MUST support limiting the number of external ports (or,
      equivalently, "identifiers" for ICMP) that are assigned per
      subscriber.

      a.  Per-subscriber limits MUST be configurable by the CGN
          administrator.

      b.  Per-subscriber limits MAY be configurable independently per
          transport protocol.

      c.  Additionally, it is RECOMMENDED that the CGN include
          administrator-adjustable thresholds to prevent a single
          subscriber from consuming excessive CPU resources from the CGN
          (e.g., rate-limit the subscriber's creation of new mappings).

   Justification:  A CGN can be considered a network resource that is
      shared by competing subscribers.  Limiting the number of external
      ports assigned to each subscriber mitigates the denial-of-service
      (DoS) attack that a subscriber could launch against other
      subscribers through the CGN in order to get a larger share of the
      resource.  It ensures fairness among subscribers.  Limiting the
      rate of allocation mitigates a similar attack where the CPU is the
      resource being targeted instead of port numbers.  However, this
      requirement is not a MUST because it is very hard to explicitly
      call out all CPU-consuming events.
==

> - Should the IP-Port-Range attribute require at least one of
> IP-Port-Ext-IPv4-Addr or IP-Port-Local-Id to be present?

[Med] No. This is deployment specific. For example, a CPE that reports the allocation of a port range to a visiting host is not required to include the external IP address given this information is already known to the RADIUS server (e.g., Figure 20). But a DS-Lite AFTR that allocates a port range may send a notification message to inform the RADIUS server about a new allocated port range, this message will include the external IPv4 address (IP-Port-Ext-IPv4-Addr) and the softwire IPv6 address (IP-Port-Local-Id)

 How is the
> attribute used when both are absent?

[Med] The text says the following: 

   If the IP-Port-Ext-IPv4-Addr TLV is included as part of the IP-Port-
   Range Attribute, the port range as specified is associated with IPv4
   address as indicated, but otherwise is for all IPv4 addresses by the
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   port device (e.g., a CGN device) for the end user.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No need to have explicit text about the absence of IP-Port-Local-Id as we thought this obviously means no extra identifier is required.

> - The summary statement associated with the attributes in section 1 might
> benefit from indicating the purpose of the attribute relative to each
> packet type in which it may appear (for example, the purpose of a port
> limit info attribute is different when included in an Access-Request than
> in an Access-Response).

[Med] IMHO this is redundant with the content of Section 5. 

> - Each attribute lists applicable packet types and indicates the attribute
> must not appear in any other packet type. It may be worth adding a note to
> clarify what should happen if the attribute does appear (assuming ignore).

[Med] This is covered in Section 5. 

> - The UE acronym on page 30 should be expanded.

[Med] Will be fixed.

> - In 3.1.2, change "are previously allocated" to "were previously
> allocated".

[Med] Will be fixed. Thank you for catching this.

> - In 4.1.3, is "RADIUS associate" a commonly used term? This seems like a
> requirement on use with CoA-Requests that should be mentioned earlier.
> 

[Med] Will be changed to "RADIUS association".