Subject: [netmod] Comment on draft-ietf-netmod-system-mgmt-05

From: Jouni Korhonen <[email-masked]>
Date: Tue, 9 Apr 2013 15:32:03 +0300

Folks,

AAA-Doctors track on all documents that specify something that
relates to AAA protocols (RADIUS/Diameter). In that light we
also occasionally provide some early comments before the I-Ds
from other WGs enter IETF LC.

Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data
model for the configuration of the RADIUS client. Has the WG
considered additional transports for RADIUS than the original
UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is
about to complete DTLS (draft-ietf-radext-dtls-04). There are
implementations already out in the field. I would envision 
different transports would have an impact to the data model
(transport type, possible TLS cipher details and credentials,
etc). Or is there a particular reason for not taking alternative
transports into account?

- Jouni (RADEXT co-chair)

---

From: Andy Bierman <[email-masked]>
Date: Tue, 9 Apr 2013 08:42:11 -0700

> etc). Or is there a particular reason for not taking alternative

thanks for the review.
How would you suggest adding this support?
The radius feature (page 12) references RFC 2865.

If the transport is something the server developer picks,
then perhaps updating the description and reference
statements for this feature is sufficient.

If the transport is something the operator picks,
then it gets more complicated. E.g.,
   - add a config=false leaf or leaf-list identifying the transports
     supported by the server
  - add a config=true leaf to the radius/server list (page 21)
    specifying the transport for the server to use
  - add new identity statements for the standard transports

> - Jouni (RADEXT co-chair)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Apr 2013 21:25:12 +0200 (CEST)

>   - add new identity statements for the standard transports

I think what is needed is more flexibility in the radius server list
(note that we only provide client-side configuration; so in the client
config we list the servers the client can talk to).  Something like
this:

   container radius {
     list server {
       key name;
       ordered-by user;

       leaf name {
         type string;  // arbitrary name
       }
       leaf address {
         type inet:host;
         mandatory true;
       }
       choice transport {
         case udp {
           container udp {
             leaf authentication-port { ... }
             leaf shared-secret { ... }
           }
         case tcp {
           container tcp {
             leaf authentication-port { ... }
             // RFC 6613 section 2.6.7 talks about config parameters
             // maybe include them here?
           }
         }
         case tls {
             leaf port { ... }
             // what else...?
           }
         }
       }
       ...
     }

Note that this is an extensible model; other transports can be added
or augmented into this structure.

One option could be to restructure like this but only actually define
the udp case above, and leave the rest (tcp, tls, dtls) for future
work.

/martin

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 11 Apr 2013 09:32:56 +0300

Martin,

> config we list the servers the client can talk to).  Something like

Something like below would be fine. Of course, it is up to Netmod to
decide what goes in and what does not. We just wanted to point out
that RADIUS has moved on and there are more tools in the box. I
would assume that TLS transport should be interesting for the
management folks.

- Jouni

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Apr 2013 07:38:33 -0700

....
>              leaf shared-secret { ... }
              if-feature radius-over-tcp;
>              // maybe include them here?
                if-feature radius-over-tls;
> or augmented into this structure.

Re: features:
Doesn't the NETCONF server decide what transports it
can use, not the client?  So new cases need to be optional.

> the udp case above, and leave the rest (tcp, tls, dtls) for future

Or just define the leafs you have here and leave
the rest for future work.

Andy