Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use reference of servers in /system/aaa/server-groups. Move the actual server list to top level of /system/aaa. #1105

Open
wants to merge 16 commits into
base: master
Choose a base branch
from
Open

Use reference of servers in /system/aaa/server-groups. Move the actual server list to top level of /system/aaa. #1105

wants to merge 16 commits into from

Conversation

WenyiChengANET
Copy link

@WenyiChengANET WenyiChengANET commented May 3, 2024 •
edited
Loading

(M) system/openconfig-aaa-radius.yang
(M) system/openconfig-aaa-tacacs.yang
(M) system/openconfig-aaa.yang

Change Scope:

Use name instead of only address as the key for a server. A server should be defined with address, port, network-instance and type. Using name as the single key because this need to be a leafref in the server group member list and multi-key ref is not well supported currently.
Deprecate port/authen-port from aaa-tacacs and aaa-radius config. Move it to server config.
Deprecate the server list in the “server-groups” container and move “servers” up to the top level for aaa.
Add a list of server ref matching the top level server list in the “server-groups” container.
This is a slow change which keeps the original nodes and marks them as deprecated.

Platform Implementations:

Arista AAA configuration:
Servers with the same host/port can be configured in different VRFs(network-instance).
One server can be added to multiple server groups.

(config)#radius-server host 1.2.3.4 vrf mgmt-vrf auth-port 123
RADIUS host 1.2.3.4 with auth-port 123 and acct-port 1813 created in vrf mgmt-vrf
(config)#radius-server host 1.2.3.4 vrf mgmt-vrf-2 auth-port 123
RADIUS host 1.2.3.4 with auth-port 123 and acct-port 1813 created in vrf mgmt-vrf-2
(config)#aaa group server radius rad-grp-1
(config-sg-radius-rad-grp-1)#server 1.2.3.4 vrf mgmt-vrf auth-port 123
(config-sg-radius-rad-grp-1)#server 1.2.3.4 vrf mgmt-vrf-2 auth-port 123
(config-sg-radius-rad-grp-1)#exit
(config)#aaa group server radius rad-grp-2
(config-sg-radius-rad-grp-2)#server 1.2.3.4 vrf mgmt-vrf auth-port 123
(config-sg-radius-rad-grp-2)#exit
(config)#show radius
…
RADIUS server-group: rad-grp-1
     0: 1.2.3.4, authentication port 123, accounting port 1813 (VRF mgmt-vrf)
     1: 1.2.3.4, authentication port 123, accounting port 1813 (VRF mgmt-vrf-2)

RADIUS server-group: rad-grp-2
     0: 1.2.3.4, authentication port 123, accounting port 1813 (VRF mgmt-vrf)
…

Arista documentation

Pyang output for the new model:
*please note that the old nodes has been removed from this output for easy review. In the actual change they are marked as deprecated.

module: openconfig-system
  +--rw system
     +--rw aaa
        +--rw config
        +--ro state
        ...<unchanged part>

        +--rw servers
        |  +--rw server* [name]
        |     +--rw name      -> ../config/name
        |     +--rw config
        |     |  +--rw name?               string
        |     |  +--rw address?            oc-inet:ip-address
        |     |  +--rw port?               oc-inet:port-number
        |     |  +--rw network-instance?   oc-ni:network-instance-ref
        |     |  +--rw type?               identityref
        |     |  +--rw timeout?            uint16
        |     +--ro state
        |     |  +--ro name?                  string
        |     |  +--ro address?               oc-inet:ip-address
        |     |  +--ro port?                  oc-inet:port-number
        |     |  +--ro network-instance?      oc-ni:network-instance-ref
        |     |  +--ro type?                  identityref
        |     |  +--ro timeout?               uint16
        |     |  +--ro connection-opens?      oc-yang:counter64
        |     |  +--ro connection-closes?     oc-yang:counter64
        |     |  +--ro connection-aborts?     oc-yang:counter64
        |     |  +--ro connection-failures?   oc-yang:counter64
        |     |  +--ro connection-timeouts?   oc-yang:counter64
        |     |  +--ro messages-sent?         oc-yang:counter64
        |     |  +--ro messages-received?     oc-yang:counter64
        |     |  +--ro errors-received?       oc-yang:counter64
        |     +--rw tacacs
        |     |  +--rw config
        |     |  |  x--rw port?                oc-inet:port-number
        |     |  |  +--rw secret-key?          oc-types:routing-password
        |     |  |  +--rw secret-key-hashed?   oc-aaa-types:crypt-password-type
        |     |  |  +--rw source-address?      oc-inet:ip-address
        |     |  +--ro state
        |     |     x--ro port?                oc-inet:port-number
        |     |     +--ro secret-key?          oc-types:routing-password
        |     |     +--ro secret-key-hashed?   oc-aaa-types:crypt-password-type
        |     |     +--ro source-address?      oc-inet:ip-address
        |     +--rw radius
        |        +--rw config
        |        |  x--rw auth-port?             oc-inet:port-number
        |        |  +--rw acct-port?             oc-inet:port-number
        |        |  +--rw secret-key?            oc-types:routing-password
        |        |  +--rw secret-key-hashed?     oc-aaa-types:crypt-password-type
        |        |  +--rw source-address?        oc-inet:ip-address
        |        |  +--rw retransmit-attempts?   uint8
        |        +--ro state
        |           x--ro auth-port?             oc-inet:port-number
        |           +--ro acct-port?             oc-inet:port-number
        |           +--ro secret-key?            oc-types:routing-password
        |           +--ro secret-key-hashed?     oc-aaa-types:crypt-password-type
        |           +--ro source-address?        oc-inet:ip-address
        |           +--ro retransmit-attempts?   uint8
        |           +--ro counters
        |              +--ro retried-access-requests?   oc-yang:counter64
        |              +--ro access-accepts?            oc-yang:counter64
        |              +--ro access-rejects?            oc-yang:counter64
        |              +--ro timeout-access-requests?   oc-yang:counter64
        +--rw server-groups
           +--rw server-group* [name]
              +--rw name             -> ../config/name
              +--rw config
              |  +--rw name?   string
              |  +--rw type?   identityref
              +--ro state
              |  +--ro name?   string
              |  +--ro type?   identityref
              +--rw group-members
              |  +--rw group-member* [name]
              |     +--rw name      -> ../config/name
              |     +--rw config
              |     |  +--rw name?   -> ../../../../../../servers/server/name
              |     +--ro state
              |        +--ro name?   -> ../../../../../../servers/server/name

@WenyiChengANET WenyiChengANET requested a review from a team as a code owner May 3, 2024 22:25
@rolandphung rolandphung mentioned this pull request May 15, 2024
Closed
@dplore
Copy link
Member

dplore commented May 15, 2024

/gcbrun

@OpenConfigBot
Copy link

OpenConfigBot commented May 15, 2024 •
edited
Loading

No major YANG version changes in commit 4ff1cbf

@WenyiChengANET
Copy link
Author

It looks like that some checks are complaining about the deref I use in path. Is deref not support in path? Pyang doesn't give me any error on that.

If it's not supported, any suggestion on how to use leafref on a node with multiple keys and make sure all keys are from the same element? Below is the code using deref in the PR:

  grouping aaa-servergroup-member-config {
    description
      "Common configuration data for server group member";

    leaf address {
      type leafref {
        path "../../../../../../servers/server/address";
      }
      description
        "Reference to the configured address of the server group member";
    }

    leaf port {
      type leafref {
        path "deref(../address)/../port";
      }
      description
        "Reference to the configured port of the server group member";
    }

    leaf network-instance {
      type leafref {
        path "deref(../port)/../network-instance";
      }
      description
        "Reference to the configured network-instance of the server group member";
    }

    leaf type {
      type leafref {
        path "deref(../network-instance)/../type";
      }
      description
        "Reference to the configured type of the server group member";
    }
  }

@earies
Copy link
Contributor

earies commented May 15, 2024

It looks like that some checks are complaining about the deref I use in path. Is deref not support in path? Pyang doesn't give me any error on that.

deref() is a valid YANG 1.1 XPath function - OpenConfig models are 1.0 based

deref() is also not a permitted path-arg in 1.1

https://datatracker.ietf.org/doc/html/rfc7950#section-9.9.2
https://datatracker.ietf.org/doc/html/rfc7950#page-205

@AI-Complete
Copy link

Wendyi who did you request review this commit?

@WenyiChengANET
Copy link
Author

Removed deref from the path. Use name as the single key for server and as the leafref in server group member list.

@dplore
Copy link
Member

dplore commented May 29, 2024

/gcbrun

@dplore
Copy link
Member

dplore commented May 30, 2024

/gcbrun

@dplore
Copy link
Member

dplore commented Jul 8, 2024

/gcbrun

@dplore
Copy link
Member

dplore commented Aug 13, 2024

Placeholder note for myself, this change looks like it is needed for supporting aaa servers that have the same IP address but are in different network instances, is that right @WenyiChengANET ?

@WenyiChengANET
Copy link
Author

Placeholder note for myself, this change looks like it is needed for supporting aaa servers that have the same IP address but are in different network instances, is that right @WenyiChengANET ?

This is correct. It also moves the servers list out from server-groups and puts it on the top level, so that the same server can be added to multiple groups without having duplicated copies.

@dplore
Copy link
Member

dplore commented Oct 17, 2024

/gcbrun

@dplore
Copy link
Member

dplore commented Oct 23, 2024

/gcbrun

@dplore
Copy link
Member

dplore commented Oct 31, 2024

/gcbrun

@dplore
Copy link
Member

dplore commented Oct 31, 2024 •
edited
Loading

This change is needed for configuring AAA servers in network-instances. I also observe 3 implementations which already support single and server group based configuration.

Quoting more implementation references:

Arista EOS documentation shows server and server group configuration.

Cisco IOS XR supports single aaa server and grouped aaa server configuration.

JunOS supports group and single server configuration (the example uses a group, but it is mentioned that the group is optional).

SRLinux appears to only support aaa configuration in a group

@dplore
Copy link
Member

dplore commented Oct 31, 2024

Setting last call to Nov 14, 2024

@dplore dplore added the last-call PR that is in final review before merging. label Oct 31, 2024
@dplore dplore mentioned this pull request Nov 1, 2024
Open
@dplore dplore linked an issue Nov 1, 2024 that may be closed by this pull request
Enhance OpenConfig AAA Model to Support Multiple TACACS/RADIUS Servers with Shared IP Addresses and Distinct Ports #1198
Open
@jsterne
Copy link

jsterne commented Nov 7, 2024

Should this one maybe get a bit more visibility and discussion? I don't think it has come up on the monthly vendor meeting. Although it isn't NBC right now (since the old model is still available but deprecated) it will be a breaking change later.

The references above do show implementations with servers defined outside of server-groups, but all those implementations seem to use address as the server key today.

Do any OpenConfig models actually point to an individual server rather than a server-group? Is there a plan to do so? I can see how some implementations may support that but if OpenConfig models don't refer to an individual server then is there a need to make that change in the model?

Adding the NI leafref does seem like a needed addition though.

@dplore
Copy link
Member

dplore commented Dec 3, 2024

/gcbrun

@dplore
Copy link
Member

dplore commented Dec 12, 2024

Revised last call date 2024-Dec-20

@LimeHat
Copy link

LimeHat commented Dec 12, 2024 •
edited
Loading

Deprecate the server list in the “server-groups” container and move “servers” up to the top level for aaa.

An AAA server can be used either directly by itself or within a server group, so we need this type defined per server as well.

  1. OpenConfig today does not define the usage of a single server by itself. Nor it should, in my opinion.
    Accounting and authorization method reference server groups (which makes sense) or an identity. Is there an operational use case for singular, group-independent server usage?

public/release/models/system/openconfig-aaa.yang

Lines 464 to 481 in f01a86d

leaf-list accounting-method {
type union {
type identityref {
base oc-aaa-types:AAA_METHOD_TYPE;
}
type string;
//TODO: in YANG 1.1 this should be converted to a leafref to
//point to the server group name.
}
ordered-by user;
description
"An ordered list of methods used for AAA accounting for this
event type. The method is defined by the destination for
accounting data, which may be specified as the group of
all TACACS+/RADIUS servers, a defined server group, or
the local system.";
}
}

public/release/models/system/openconfig-aaa.yang

Lines 613 to 630 in f01a86d

leaf-list authorization-method {
type union {
type identityref {
base oc-aaa-types:AAA_METHOD_TYPE;
}
type string;
}
ordered-by user;
description
"Ordered list of methods for authorizing commands. The first
method that provides a response (positive or negative) should
be used. The list may contain a well-defined method such
as the set of all TACACS or RADIUS servers, or the name of
a defined AAA server group. The system must validate
that the named server group exists.";
}
}

Vendors can decide what to do if they see a conflict between the type of the group and the type of the server.

  1. Leaving such things up to "vendors to decide" is not great since the purpose of OC is to define a consistent behavior across all implementations.

  2. This seems like a major change (which is breaking from the operational point of view, even thought not breaking in yang terms as noted by Jason) that is done with the primary purpose of aligning the OC model with the Arista's implementation.

    • As already noted by Jason, other provided references don't seem to use global servers list together with the groups [where the servers are referenced by name].
    • It is unclear whether the need for "multiple servers in the same group with the same IP address but in different network instances" is actually a real use case that cannot be solved otherwise. If an operator has multiple mgmt network instances, over which a specific server (that has a single IP) can be reached, they can use multiple groups to provide redundancy.

@rgwilton
Copy link

I've checked with the IOS XR AAA team, and we allow a server to be configured outside a server group and then referenced (but as Jason indicates it is keyed by IP address).

I think that the change that is being proposed here is more impactful than it needs to be. I.e., I suspect in some (perhaps many) cases, defining the servers under a server-group is logically the right place to put them. So, I don't think that we should be deprecating those existing leaves.

It seems that the core desire is to allow servers being listed outside server-groups, so that they can be shared across multiple groups. This seems reasonable, but I would perhaps renamed the top level list from servers to shared-servers, and rename group-members to something like shared-server-members.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dplore dplore dplore approved these changes

Assignees
No one assigned
Labels
last-call PR that is in final review before merging. non-breaking
Projects
OC Operator Review
Status: last-call
Milestone
No milestone
8 participants
@WenyiChengANET @dplore @OpenConfigBot @earies @AI-Complete @jsterne @LimeHat @rgwilton