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

[Martin Bjorklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Tue, Apr 9, 2013 at 5:32 AM, Jouni Korhonen <[e-mail]> wrote:
> > 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?
> >
> 
> 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

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