Re: [tcpm] [Idr] Last Call: <draft-ietf-tcpm-yang-tcp-06.txt> (A YANG Model for Transmission Control Protocol (TCP) Configuration) to Proposed Standard

[Mahesh Jethanandani <[e-mail]>]

[Pruning this thread to open issues]

> On Mar 2, 2022, at 6:04 AM, Jeffrey Haas <[e-mail]> wrote:
> 
>>>> From: Jeffrey Haas <[e-mail]>
>>> On Feb 25, 2022, at 7:41 PM, Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>> wrote:
>> 
>>> I think what is meant here is RNextKeyId. This is part of TCP-AO (Section 2.2 of RFC 5925). We seem to agree that the client, e.g. BGP, should maintain a reference to the keychain it is using. Does the client need to do more than providing that reference to TCP, i.e. provide the RNextKeyId?
>> 
>>>> Note that I'm not arguing that this state is config state at all.  I think this one is likely operational-only state.
>>>> But that rather argues what the glue is for the configuration.  And that's where the conversation below gets interesting.
>> 
>> [ms] We never discussed whether additional operational state is needed for TCP-AO. It is a good question, though. Whether we go down that road probably depends also on how we further proceed with TCP-AO configuration.
> 
> Agreed, in general.  The specific bit of state cited here, RNextKeyId, is
> ideally short-lived operational state for when a key rollover in TCP-AO
> happens.  It is primarily useful for "stuck" key roll overs.

I will add RNextKeyId as a ro node to the AO configuration.

> 
>>>> - The states exposed in the model are incomplete.  While they cover much
>>>> that is from the TCP-MIB (as noted by the discussion text), some things
>>>> like FIN_WAIT* are very helpful for troubleshooting stuck TCP sessions or
>>>> socket exhaustion.
> 
>> [ms] There was some discussion in TCPM on whether to focus on the base statistics from the TCP MIB (RFC 4022), or whether to include more stats. Note that there is a TCP Extended Statistics MIB (RFC 4898), but at least I am not aware of any implementation of that MIB.
> 
> Understood.  See near top of message my opinion on such things.
> 
> That said, tcp state for things like FIN_WAIT* are well deployed in my
> experience.  (And sadly, to my operational experience in trying to
> troubleshoot network and stack issues.)

I will wait for the WG to comment on whether they want to include TCP connection state in the model.

> 
>> [ms] The stats defined by the TCP MIB are supported not only on several router operating systems, but e.g. also on Linux (/proc/net/snmp on a Debian Buster system). Also, there have been a report that Windows uses global stats along the lines of the MIB definitions (see  https://mailarchive.ietf.org/arch/msg/tcpm/3oMQdIrz9prgE1smt-aFTEFpqGs/ for details). Of course, operating systems may have useful stats beyond the TCP MIB. For instance, in Linux the “netstat -s” command reports also counters beyond the TCP MIB, including a counter related to FIN_WAIT, but at least some of these counters reported by “netstat -s” are Linux-specific, as they refer to Linux-internal heuristics. So, sure, we can add further stats to the YANG model, but then we need a very careful analysis whether these stats are indeed reasonably similar implemented. I have done such an analysis for some other TCP configuration parameters and even for pretty trivial parameters the existing running TCP code differs significantly. There is a significant risk that whatever we would write in a YANG model deviates from running code. TCP-AO may be partly an exception because the implementations are all fairly new.
> 
> In some of my prior kernel browsing for various operational state, I've seen
> that the stats are literally named after the old MIB variables.  So, there's
> examples of providing stats because standards work motivated it.
> 
> I don't advocate trying to cover everything.  For IETF work, what I
> generally advocate for is things that the protocol specifications lead to.
> Session state should be an easy answer.
> 
> For other things that are less supportable by common reference to RFCs but
> may be widely but not pervasively deployed, YANG module authors have a
> choice: Don't put it in, and permit implementors to augment the feature into
> the model.  Put it in, and require implementors to deviate features they
> don't support.
> 
> YANG, at least, gives us the easy option for such augmentations and
> deviations.  It'll be up to the wisdom of the contributors to the Working
> Group as to what makes sense in such circumstances.

Again, I will wait for the WG to comment on what additional stats if any need to be included in the model.

> 
>> [ms] The TCP connection table is *not* intended for configuration state.
> 
> Then you have an example that needs work. :-)

Which example are you referring to? 

If you are referring to the example in B.2 - TCP-AO configuration, you will notice that the TCP-AO configuration has two parts. One part, which is state or ‘config false’ data and includes the local and remote-address; local and remote port. The other part is the AO parameters such as ‘recv-id’ and ’send-id’ which is configuration or ‘config true’ data. There is an existing draft System-defined Configuration <https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-02#section-4.5.3>, that gets into how one can use state data (connection 4-tuple), to configure the TCP-AO parameters (config true), but the short of it is that till that draft becomes a RFC, the only way to model all the parameters as either ‘config true’ or ‘config false’. I chose the former.

> 
>> I have been told that this list has to be read-write because of YANG semantics, albeit a large part of the content is read-only.
> 
> I would be curious to see the YANG doctor analysis that lead to this
> decision.  Do you have a pointer?

See above.

> 
>> The document already explains this as follows: “TCP connection table: Access to status information for all TCP connections.  Note, the connection table is modeled as a list that is read-writeable, even though a connection cannot be created by adding entries to the table.  Similarly, deletion of connections from this list is implementation-specific.” I agree that if a TCP connection were to be established by that table, wildcards would be needed 
> 
> Asking a simple "netstat" question: How do you model sockets in the LISTEN
> state?  For such sockets, how do you model listening on one address or a
> wildcard address?
> 
>> – but in reality TCP connections are established by the application or service, e.g. by the sockets API. One doesn’t use a YANG model for that, at least as far as I know. If the list only includes established TCP connections, every single TCP connection has a well-defined src/dst IP address and a well-defined  src/dst port (5-tuple); on the connection initiator side, src address and src port may be selected by the stack. The current model in draft-ietf-tcpm-yang-tcp-06 also does not model a list of listeners.
> 
> My point is made for listeners.  I believe this is a model gap.

One way that I have seen this modeled is as follows.

    leaf-list listen-addresses {
      type union {
        type inet:ip-address;
        type enumeration {
          enum any {
            description
             "The agent should listen on any address
              bound to an interface on the system.";
          }
        }
        type string;
      }
      default “any";
      must "(not(../listen-addresses = ‘any' and count(../listen-addresses) > 1))" {
        error-message “‘any', IP addresses, and interface names are mutually exclusive";
      }
      description
        "The IP addresses that the agent should
         listen on. This may be an IPv4 or an IPv6 address, interface name 
         or the enum ‘any’.";
    }


> 
>> [ms] In a nutshell, if connections cannot be created by adding entries to the list, I don’t understand why wildcards would be needed.
> 
> For operational state for listeners.  That said, I'm less advocating for
> "create a connection in this table" and more about "how does a TCP client
> wanting to use TCP-AO get its job done?"

Things get interesting when you try to configure TCP-AO parameters using this model. Theoretically, one does not know the 4-tuple for a given connection, till the connection is already established, by which time it is already too late to provide the AO parameters, as they would be needed at connection establishment time. So the short answer is, I do not know.

> 
>>>> + The binding between a send-id and receive-id likely belong in the
>>>>   keychain.  This likely requires augmenting the keychain model.
>> 
>>> Did you mean binding between tcp-ao and the keychain model it is using?
>> 
>> I mean that send-id/receive-id state likely belongs in an individual keychain entry.  That means the keychain model needs augmenting.  The augmentation can be sourced from the tcpm RFC.
>> 
>> [ms] That solution (used by all known router implementations) is already explicitly explained in draft-ietf-tcpm-yang-tcp-06 as follows: “The keychain for TCP-AO can be modeled by the YANG Data Model for Key Chains [RFC8177].  The groupings defined in this document can be imported and used as part of such a preconfiguration.”
> 
> I don't find the example clear.  As noted above, configuration state in
> existing implementations requires a binding of a send-id and a receive-id
> (TCP-AO configuration state) to the keychain entry.

Binding is what the example in Section B.2 is trying to demonstrate. The send-id (61) and recv-id (84) are bound to the keychain “ao-config”.

I will model in the RNextKeyId parameter, but the keychain model is not clear in how it is going to use the RNextKeyId, or how the key rollover happens. And draft-ietf-tcpm-ao-test-vectors <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ao-test-vectors> does not have an example for RNextKeyId. I can assume the bindings are similar, and bind RNextKeyId to the keychain “ao-config’, and a keystring of ‘testvector’ much like ‘recv-id’ and ’send-id’. How does that sound?

Thanks.

Mahesh Jethanandani
[e-mail]