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

["Scharf, Michael" <[e-mail]>]

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 <[e-mail]>
Sent: Sunday, February 27, 2022 11:49 PM
To: Mahesh Jethanandani <[e-mail]>
Cc: [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:

FYI..


On February 16, 2022 at 5:44:30 PM, The IESG ([e-mail]<mailto:[e-mail]> <mailto:[e-mail]>) 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
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]> mailing lists by 2022-03-02. Exceptionally, comments may
be sent to [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> 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
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>


Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>