Subject: Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext

From: <[email-masked]>
Date: Thu, 28 Jul 2016 08:00:26 +0000

Dear Kathleen,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : radext [mailto:[email-masked]] De la part de Kathleen
> Moriarty
> Envoyé : jeudi 28 juillet 2016 02:58
> À : [email-masked]
> Objet : [radext] AD Review of draft-ietf-radext-ip-port-radius-ext
> 
> Hello,
> 
> Thank you for your work on draft-ietf-radext-ip-port-radius-ext.  This
> is an easy to understand document.  I found a few nits and think more
> text is needed in the security considerations section.  My review is
> below.
> 
> 
> Abstract
> second sentence nit: s/implementing/implement/
[Med] Fixed. 

> From: For devices that
>    implementing 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.
> To: 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.
> 
> 2. Terminology
> 
> I think some rewording is needed, 'in respective' doesn't quite fit in
> the following definition:
> 
>     External realm: refers to the networking segment where external IP
>       addresses are used in respective of the device supporting port
>       ranges.
[Med] Changed to: 

External realm: refers to the networking segment where external IP addresses are used as source addresses of outbound packets forwarded by a device supporting port ranges.

Better?

> In the following definition, expand out CGN.

[Med] CGN is already expanded in the introduction.

 I am pretty sure the
> others are acronyms that are in the do not have to expand list.  This
> one isn't one that I am familiar with:
>   o  Port-based device: a device that is capable of providing IP
>       address and IP port mapping services and in particular, with the
>       granularity of one or more subsets within the 16-bit IP port
>       number range.  A typical example of this device is a CGN, CPE,
>       Provider WLAN Gateway, etc.
> 
> Section 4.1.2: s/once/one/
[Med] Fixed. 

>    As one practice, a CGN may allocate a bulk of TCP/UDP ports or ICMP
>    identifiers once at a time for a specific user,
> 
> Security considerations:
> 
> Shouldn't there be some considerations about the communications for
> these attributes between the radius server and NAt44 or other devices?

[Med] I don't think this is specific to these attributes but this is applicable to all RADIUS applications. 

>  Since these attributes can be used to communicate a change in
> permissions (port/address mappings) that open/shut permissions for a
> user, the user could be subject to attacks by alterations or tampering
> of this stream.  One might be to allow ports to be open that would
> make the system vulnerable to attack.  The other would be to close
> ports off that are needed, resulting in a denial of service.
> 
> I would think there are considerations to list with each of the new
> attributes along these lines.  This would be specific text to the
> added attributes and communication of these attributes on the wire.

[Med] The root cause of these attack vectors is the communication between the RADIUS client/server. Saying that, what about making this change to illustrate some attacks as you suggested?

OLD:
   This document does not introduce any security issue other than the
   ones already identified in RADIUS [RFC2865].

NEW:

   This document does not introduce any security issue other than the
   ones already identified in RADIUS [RFC2865] and [RFC5176] for CoA
   messages.  Known RADIUS vulnerabilities apply to this specification.
   For example, if RADIUS packets are sent in the clear, an attacker in
   the communication path between the RADIUS client and server may glean
   information that it will use to prevent a legitimate user to access
   the service by appropriately setting the maximum number of IP ports
   conveyed in an IP-Port-Limit-Info attribute, exhaust the port quota
   of a user by installing many mapping entries (IP-Port-Forwarding-Map
   attribute), prevent incoming traffic to be delivered to its
   legitimate destination by manipulating the mapping entries installed
   by means of an IP-Port-Forwarding-Map attribute, discover the IP
   address and port range assigned to a given user and which is reported
   in an IP-Port-Range attribute, etc.  The root cause of these attack
   vectors is the communication between the RADIUS client and server.

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

Better?

> 
> Let me know if I am missing something as to why this is already
> covered in radius security considerations.  I think the specific
> attribute addd should have their concerns listed.
> 
> Thanks!

[Med] Thank you for the review.

> --
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: [email-masked]
Date: Thu, 28 Jul 2016 10:08:23 -0400

Hello Mohamed,

Thank you for the quick response. Inline

Sent from my iPhone

> On Jul 28, 2016, at 4:00 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Dear Kathleen,
> 

Yes, thank you!
>   optionally secured by IPsec or Transport Layer Security (TLS)

Much, thanks!  This hits the point on what can be fine with these attributes over existing/known weak points in the protocol and I appreciate the recommendation to run it with an encrypted session.

Once the shepherd report is ready, I'll put it in IETF last call.

Thanks,
Kathleen

---

From: <[email-masked]>
Date: Thu, 28 Jul 2016 14:28:17 +0000

Re-,

Thank you, Kathleen. 

FYI, an updated version with these changes is available online. 

Cheers,
Med 

> De : [email-masked]
> [mailto:[email-masked]]
> Envoyé : jeudi 28 juillet 2016 16:08
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> Objet : Re: [radext] AD Review of draft-ietf-radext-ip-port-radius-ext
> 
> Hello Mohamed,
> 
> addresses are used as source addresses of outbound packets forwarded by a
> device supporting port ranges.
> >
> > Better?
> 
> Yes, thank you!
> >
> > [Med] The root cause of these attack vectors is the communication
> between the RADIUS client/server. Saying that, what about making this
> change to illustrate some attacks as you suggested?
> >
> > OLD:
> Much, thanks!  This hits the point on what can be fine with these
> attributes over existing/known weak points in the protocol and I
> appreciate the recommendation to run it with an encrypted session.
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 Jul 2016 12:29:07 -0400

> FYI, an updated version with these changes is available online.

Excellent, thank you!  I see the shepherd report id posted, so I'll
review that and progress the draft to IETF review.  This and the other
Radext draft will likely be on the telechat in 3 weeks.  Next weeks
telechat is packed already, so I was avoiding it (Better reviews and
less cranky ADs :-) .

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 Jul 2016 14:34:05 -0400

Hello Mohamed,

I just read through the shepherd report and see that Stefan caught
that the abstract doesn't list the RFC that this updates.  Can you
make that fix and once that is done, I'll start IETF last call so this
comment doesn't come up again.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 Jul 2016 14:42:40 -0400

Oops, wrong radext draft!

This shepherd report looks great, just one nit for Lionel to fix when
he has a moment, but I won't hold up on a nit in the shepherd report -

s/vie/view/

In the approach 1, using fixed values for sub-TLV used in any
attribute is straightforward from a dictionary/configuration point of
vie, i.e.

Thanks,
Kathleen

-- 

Best regards,
Kathleen