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

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 2 Mar 2022 10:53:54 +0000

Jeff, all,

Thanks a lot for these good comments. As suggested below, I have put the TCPM list in CC in order to ensure that TCPM is in the loop.

Below are some further comments from me as author below, marked by [ms].

From: Jeffrey Haas <[email-masked]>
Sent: Sunday, February 27, 2022 11:49 PM
To: Mahesh Jethanandani <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Last Call: <draft-ietf-tcpm-yang-tcp-06.txt> (A YANG Model for Transmission Control Protocol (TCP) Configuration) to Proposed Standard

On Feb 25, 2022, at 7:41 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

[Moving Alvaro to Bcc: and pulling in the authors of TCP YANG]

Thanks Jeff for highlighting these issues. I am glad you caught them.

We desperately need to find a way to stop having me be the only one that notices this sort of thing.  Especially last second. :-)

Michael and Vishal, the context of this thread is the interconnect between BGP YANG model, and the TCP YANG model. In particular, it is use of TCP-AO to secure the BGP session, but there are other issues also. Jeff in his analysis of the TCP YANG model has pointed out a few things we need to discuss. If this needs to be taken back to the tcpm mailing list, please do so.

I'd argue that the config state as a way of using the feature is outright unusable and that's probably a reason of its own to send things back.

That said, there's perhaps room to just clean up and do operational state... but you probably want to finish the whole thing.

More below.

On Feb 25, 2022, at 1:40 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:

Alvaro,

We spent time talking about this set of issues in the tcpm model as part of
our BGP YANG meeting this week.  I believe I've convinced Mahesh that there
are several issues.  I wanted to make sure you're aware of that so you don't
try to push things along without closing those loops.

Summary of some of the items, and hopefully Mahesh completes the notes:
- Missing operational state such as RNextId, perhaps SNE - although that one
 has security impliciations.

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.

- 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.

There was some discussion around what stats need to be defined, and it went something like this. This is TCP server configuration on a router. There are very few TCP sessions in the established state on a router. So a minimal set should do. For that reason, stats need not be maintained at the same level as would be on a normal TCP server.

YANG modules aren't only for routers so I don't know that is an appropriate metric for what belongs in this module.

The above point was something I specifically looked for because it's common troubleshooting for when you have stuck sessions or denied sessions.  So, I was rather surprised to not see it in the model.

And that said, while I'm a bit better informed as a power TCP user due to BGP troubleshooting issues from over the years, this is something where real experts likely have more subtle opinions.  Large scale web farm sysadmins, for example.

[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.

[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.

[ms] Finally, the past discussions in TCPM have quite clearly shown that TCP implementers focusing on client and server operating systems hardly care about YANG models at all. YANG may not play an important role in that space. This is also one of the reasons why draft-ietf-tcpm-yang-tcp explicitly focuses on what is needed on a router.

- Configuration state model is not correct for typical TCP   use:
 + Listeners are usually wildcard for remote src address and port, they
   only specify the local address (if not wildcard) and port.
 + Connector usually specifies a dst-address and port, may specify a local
   address or let it be chosen, and similarly rely on the stack to supply the
   local port.
 + The result is you can't use the config state tables to setup a session
   for an arbitary user.
 + The ipsec module from i2nsf had the issue and received similar analysis
   on list a little while back.

We can make the local and remote address a union of ip-address and a string. The string can be a ‘*’ to indicate wildcard. Similarly for port, the union would be between a port-number and a string.

I'm very much in favor of "whatever works".  But I suspect that some distinguished value makes better sense than a magic string.  An identity, perhaps?

(And yes, I know an identity ends up being a string in many rendering contexts.  Pay no attention to the man behind the curtain...)

[ms] The TCP connection table is *not* intended for configuration state. 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. 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 – 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.

[ms] In a nutshell, if connections cannot be created by adding entries to the list, I don’t understand why wildcards would be needed.

- Configuration state model is not right for keychain integration:
 + The example tries to make the key id that is the container list key the
   same as the protocol send-id/receive-id.  That's not correct.

Will fix the example.

 + 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.”

[ms] Now, the challenge is that this solution would require an update to RFC8177, and I don’t know if and when this would happen. One option would just to define the grouping in draft-ietf-tcpm-yang-tcp and do not define its use in the keychain, i.e., to leave that open until a 8177bis document is done. We tried to find an alternative that can work with the existing RFC8177 model instead. That does not prevent use of the grouping in a future key-chain standard.

 + Key rollover procedures need to be clarified.  Does it happen because
   someone changes keychain name, or updates a property of the keychain?  The
   result would be a TCP-AO next-id action.

Isn’t this something for the keychain model to clarify?

This is something for the general operational model to clarify.  If it lives in the keychain, would rollover require changes to the core keychain model or will it involve the details of what is put in the keychain augmentations to support tcp-ao?

End of the day, treat this exercise from the perspective of an end-user:
- They need to provision TCP-AO for their client protocol.  Right now, that's via a keychain ID.
- They need to setup the keychain properties.
- The keychain properties will need TCP-AO send-id/receive-id as part of the provisioning.
- The tcp module will need to have those keychains provisioned in for send and receive with the wildcarding previously discussed.
  + This potentially could happen in the yang model.  Most of the rest happens in the socket APIs:
  + The listen socket or sockets need to bind one or more keychains that match on receive-id to demux into the right keychain.
  + The connector similarly sets send/receive context with some unknowns.
  + This likely never happens via config state being set in the model - it's done via a client.
     * The implication is thus perhaps that it's only operational state you have in the model for this stuff for individual sessions.

[ms] I agree that a TCP connection will typically *not* be set up by configuration state but instead by the socket APO. Thus the connection list is most likely operational state only. The unknown is how TCP-AO configuration would be provisioned in that case. If it is indeed done by the key-chain, we may not require corresponding configuration state in draft-ietf-tcpm-yang-tcp.

[ms] I’d also like to note that there is a related problem for TCP keep-alives (which matter more for NETCONF than for BGP, as far as I understand). The actual configuration of TCP keep-alives on a new TCP connection would most likely be done by the corresponding (NETCONF) client or server application (e.g., draft-ietf-netconf-tcp-client-server). Yet, for an established TCP connection these keep-alive parameters could also be changed, and this could be done by a TCP connection list entirely independent of the client or server application. If we want to allow that change, the TCP keep-alive configuration in the list has to be configuration state, and this is what draft-ietf-tcpm-yang-tcp-06 assumes. Well, we could decide not to allow such changes in existing connections via draft-ietf-tcpm-yang-tcp. Then the entire connection list would probably have operational state only. That could possibly simplify some things. But I really wonder if that is the only solution?

Thanks

Michael

-- Jeff

And those things were the main high-level analysis.  I recommend that the
authors work through the inter-work for a random tcp-ao user to figure out
how to actually use it like the Cisco/Juniper/Linux tcp-ao implementations.

I think Mahesh has the token to move this work forward.  The BGP model is
thus far unimpacted.

If the tcpm group needs help with the discussion on these details, I'm happy
to provide it.  However, I'm not a list member and would prefer to be
brought in more in a unicast fashion if needed.

When we're back to a point of review, let me know.

-- Jeff

On Tue, Feb 22, 2022 at 04:49:47PM -0500, Jeffrey Haas wrote:

Alvaro,

Now that I've been prodded to think about this, I have some serious usability concerns.  Mahesh can tell you that a big part of what I've been trying to drive in the bgp yang work aside from maintainability is "how do you get these modules to all work together?"

I don't think this exercise was done for tcp-ao.  Looking at 8177 it probably works for md5, but even that will take me some actual thinking and review.

The timing here is lousy.  While I'm happy to provide review, I don't know that I can do so in a timely fashion.  I've already been starving the BGP YANG work because of other things.

What do you suggest here?  Send this back to tcpm to build the examples?

-- Jeff

On Feb 22, 2022, at 3:42 PM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

FYI..

On February 16, 2022 at 5:44:30 PM, The IESG ([email-masked]<mailto:[email-masked]> <mailto:[email-masked]>) wrote:

The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'A YANG Model for
Transmission Control Protocol (TCP) Configuration'
<draft-ietf-tcpm-yang-tcp-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]> mailing lists by 2022-03-02. Exceptionally, comments may
be sent to [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

This document specifies a minimal YANG model for TCP on devices that
are configured by network management protocols. The YANG model
defines a container for all TCP connections and groupings of
authentication parameters that can be imported and used in TCP
implementations or by other models that need to configure TCP
parameters. The model also includes basic TCP statistics. The model
is compliant with Network Management Datastore Architecture (NMDA)
(RFC 8342).

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/ <https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/>

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 2 Mar 2022 09:04:22 -0500

Michael,

> Thanks a lot for these good comments. As suggested below, I have put the TCPM list in CC in order to ensure that TCPM is in the loop.

Thanks.  Please note that I don't otherwise participate in tcpm and wouldn't
see additional threads spawned from this one unless explicitly copied.

I do want to front load one particular comment: Especially for operational
state, standards are sometimes the motivator for network components to
provide implementations to access that state.  I realize there is a tension
to try to limit work to things that exist in the field, but I also believe
we're at an inflection state similar to where we were when MIBs started to
become popular.  You will thus find me advocating in many cases for useful
operational state in the model even if it may not be commonly deployed at
the moment.

That said, this isn't my model and I am just one person who has spent too much
time in netstat variants.  These are just my opinions.

> [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 T…

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.

> [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 (RF…

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.)

> [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 t…

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.

> [ms] Finally, the past discussions in TCPM have quite clearly shown that TCP implementers focusing on client and server operating systems hardly care about YANG models at all. YANG may not play an…

The network industry is currently in a management tooling interregnum.  IETF
no longer creates MIBs.  SNMP and MIBs were the only tools that were being
provided for general purpose network management.  IETF shifted its work to
YANG and protocols in the netconf suite.  Many industries are waiting for us
to finish our various bits of work so they can get on with the boring task
of satisfying network monitoring needs.

I haven't done larger scale sysadmin work in years.  But for my friends who
do it, SNMP is still used in their environments because that's what's
available.

I'm not advocating any specific IETF Working Group try to own the task of
shifting the industry to use modern tooling.  The best we can do is supply
good models so that when tooling catches up the models are available.

> [ms] The TCP connection table is *not* intended for configuration state.

Then you have an example that needs work. :-)

>  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?

>  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.

> [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?"

> [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 Mod…

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.

> [ms] Now, the challenge is that this solution would require an update to RFC8177, and I don’t know if and when this would happen. One option would just to define the grouping in draft-ietf-tcpm-yan…

I will, perhaps unpopularly, argue that its dereliction of duty to throw
your hands up and say "we can't get our responsible component to work
because of someone else's work".

If you own the YANG model for TCP-AO, you're responsible for figuring out
how it should work.

If you can do it solely within your module, this is easy and done.

What is far more likely is that TCP-AO state needs to be coupled in with the
keychain.  If this can be done in a way that lets you satisfy providing a
useful model for TCP-AO by augmenting the keychain model, that's a
reasonable path forward.  Simply defining a grouping isn't the full extent
of the work, defining the augmentation would be.

If your analysis (because you're the group with the expertise) is that
configuration of TCP-AO does require binding of configuration state from
TCP-AO into the keychain, but the keychain has structural issues that
prevent this from being current viable, IETF as a whole has a problem: The
modules don't inter-work.

What should IETF do when such inter-work issues are identified?  Fix them.

What should tcpm or other Working Groups do about configuration state if
such inter-work issues are identified?  Perhaps hold up publishing your
model until it can be fixed - the process for fixing YANG models is painful
even for trivial things much less things that will require restructuring.
Alternatively, if operational state is fine, perhaps configuration state is
deferred to a later model while working through the issue with the other
dependent Working Groups.

> [ms] I agree that a TCP connection will typically *not* be set up by configuration state but instead by the socket APO. Thus the connection list is most likely operational state only. The unknown i…

That's a possible way this goes.

But if the answer is that it belongs in the keychain model and the
configuration state is motivated by TCP-AO, it's reasoanble this Working
Group supplies that model.  Alternatively, this Working Group initiates the
inter-working group discussion to solve the broader problem.

Such inter-work discussions are effectively why I'm here wearing my BGP YANG
hat. :-)

> [ms] I’d also like to note that there is a related problem for TCP keep-alives (which matter more for NETCONF than for BGP, as far as I understand). The actual configuration of TCP keep-alives on a…

I did find the structure of the keepalives a bit peculiar.  This felt less
like a general TCP mechanism and more about supporting netconf.

For things that are related to "system tuning", you're left with an
interesting set of modeling problems.  If you're in need of letting the system
tune individual sessions, you could permit the objects in an otherwise
operational state model to be read-write.  However, I suspect your YANG
doctors would suggest that doing so leads people to the peculiar observation
that they should be able to create configuration state for such sessions.

Far more likely is you include action statements in the relevant portion of
the operational tree:
https://datatracker.ietf.org/doc/html/rfc7950#section-7.15

Or alternatively, you create an RPC for the module:
https://datatracker.ietf.org/doc/html/rfc7950#section-7.14

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 8 Mar 2022 15:13:34 -0800

[Pruning this thread to open issues]

> On Mar 2, 2022, at 6:04 AM, Jeffrey Haas <[email-masked]> wrote:
> 

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

> 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.

> 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.

> 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.

> decision.  Do you have a pointer?

See above.

> 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’.";
    }

> 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.

> (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
[email-masked]