search

boucadair / secure-tacacs-yang

Other
0 stars 1 forks source link

General questions on the model #1

Open lana-wu opened 3 months ago

lana-wu commented 3 months ago
  1. "server":"domain-name" is useful to add. While "remote-address" seems redundant with the existing "address" and "port” of the tacacs server. Could you explain why the remote-address list is needed?
  2. "security": Not sure why "keepalive" defined.
boucadair commented 3 months ago
  1. "server":"domain-name" is useful to add. While "remote-address" seems redundant with the existing "address" and "port” of the tacacs server. Could you explain why the remote-address list is needed?

This is to cover the case of dual-stack server or servers that have the same name but are reachable with distinct IP addresses (redundancy).

2. "security": Not sure why "keepalive" defined.

This one I'm not sure we will keep it. I sent a message on the list raising this point. I added it in -00 to be consistent with the scope of TLS client grouping (defined in netconf), but if we don't need it we will remove it.

lana-wu commented 3 months ago
  1. "server":"domain-name" is useful to add. While "remote-address" seems redundant with the existing "address" and "port” of the tacacs server. Could you explain why the remote-address list is needed?

This is to cover the case of dual-stack server or servers that have the same name but are reachable with distinct IP addresses (redundancy).

For the TACACS+ client, either IPv4 or IPv6 can be used. TACACS+ server may support dual stack configuration. But here we are configuring TACACS+ client, not server.

boucadair commented 3 months ago

Sure. But, the list is about the addresses of the remote server:

+--rw remote-address* [address]
|  +--rw address        inet:ip-address
|  +--rw port-number?   inet:port-number
lana-wu commented 3 months ago

From the device (router, switch) configuration point of view, tacacs+server is the remote server. The existing "address" refers to the address of the remote server.

boucadair commented 3 months ago

Yes, but only one address can be configured for the same server identifier by a name. Here is what we have currently in the draft:

`'remote-address': Specifies a list of IP address/port numbers that can be used to reach a server instance.

A server instance may be identified by an IPv4 address, IPv6 address, or both.

One or multiple addresses of the same address family may be provided.

The same or distinct port numbers may be used per address family.

This container takes precedence over "address" and "port" data nodes defined in [RFC9105].`

Do you think we need to make this clearer?

lana-wu commented 3 months ago

Is dual-stack remote address configuration a corner case? I was thinking that dual-stack servers make sense to support both IPv4 and IPv6 devices. However, for a dual stack device, you can select one address family, not need to configure two addresses at the same time.

boucadair commented 3 months ago

The intent here is to cover not only dual stack but when there are more addresses to reach the same server identifier by the same domain-name for redundancy and so on. We could configure two sever entries, but then all the credentials will need to be repeated for each member of the group. Also, if there is a proceed to fall back when an instance is not responsive, that will be difficult to control with the separate entries. That's not optimal.

lana-wu commented 3 months ago

Current non-tls model defines the server list for redundancy. If one server fails to be connected, try next one. I agree the credentials configuration of TLS 1.3 is complex, and I see the current syslog YANG is also designed like this: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-32#section-5.1. How about defining templates to reuse the credentials configuration of the client?

boucadair commented 3 months ago

Current non-tls model defines the server list for redundancy. If one server fails to be connected, try next one.

This is not optimal if we want to enable HE (RFC 8305).

I agree the credentials configuration of TLS 1.3 is complex, and I see the current syslog YANG is also designed like this: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-32#section-5.1. How about defining templates to reuse the credentials configuration of the client?

Can you please take this one to the list? We need to have more opinions on this. Thanks.