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 the list down to the issue of TCP-AO configuration]

Hi Jeff,

> On Mar 2, 2022, at 6:04 AM, Jeffrey Haas <[e-mail]> wrote:
> 
>>>> 
>>>> + 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.

Ok.

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

Augmentation is certainly one way to make the binding, but may not be the only way. I propose that the TCP model include a reference to the keychain model. As modified, there is now a keychain reference on a per connection basis that can be used for either TCP-AO or MD5. Here is what the modified tree diagram looks like:

  +--rw tcp!
     +--rw connections
     |  +--rw connection*
     |          [local-address remote-address local-port remote-port]
     |     +--rw local-address     inet:ip-address
     |     +--rw remote-address    inet:ip-address
     |     +--rw local-port        inet:port-number
     |     +--rw remote-port       inet:port-number
     ….. <stuff deleted>
     |     +--rw authentication
     |        +--rw keychain?
     |        |       key-chain:key-chain-ref
     |        +--rw (authentication)?
     |           +--:(ao)
     |           |  +--rw enable-ao?             boolean
     |           |  +--rw send-id?               uint8
     |           |  +--rw recv-id?               uint8
     |           |  +--rw include-tcp-options?   boolean
     |           |  +--rw accept-key-mismatch?   boolean
     |           |  +--ro r-next-key-id?         uint8
     |           +--:(md5)
     |              +--rw enable-md5?            boolean

The example in the draft has been updated to reflect this change. Let me know if this looks good. The full set of changes can be found here <https://github.com/mjethanandani/ietf-tcp/pull/84>.

Separately, the BGP YANG model can now remove the container for secure-session, leaving it up to this model to define how a TCP connection is secured. 

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


Mahesh Jethanandani
[e-mail]