Re: [tcpm] Roman Danyliw's Discuss on draft-ietf-tcpm-yang-tcp-07: (with DISCUSS and COMMENT)

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

Hi Roman,

Thank you for this feedback and sorry for staying silent during the holiday season.

The authors have prepared a new version -08. Please refer to https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-yang-tcp-08 to see the changes.

Unfortunately, when preparing -08, one of the patches got lost, and therefore one change regarding one of your concerns is still missing in -08. Sorry! This was not intended, and this bug will be fixed in the next version -09. The suggested change for -09 is explained below.

> -----Original Message-----
> From: Roman Danyliw via Datatracker <[e-mail]>
> Sent: Wednesday, June 29, 2022 5:26 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Roman Danyliw's Discuss on draft-ietf-tcpm-yang-tcp-07: (with
> DISCUSS and COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-tcpm-yang-tcp-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> ** B.2.  Thanks for providing an example of a TCP-AO configuration.
> Unfortunately, this isn't a valid example example and it seems to be making
> citations that don't match.  Specifically:
> 
> -- "<crypto-algorithm>hmac-sha-256</crypto-algorithm>"
> 
> The algorithms usable by TCP-AO come from
> https://www.iana.org/assignments/tcp-parameters/tcp-
> parameters.xhtml#tcp-parameters-3.
>  Only SHA1 and AES128 are registered.  As far as I tell, the only work to add
> SHA256 is in an unadopted and expired draft
> (https://datatracker.ietf.org/doc/draft-nayak-tcp-sha2/).
> 
> As aside, I think the algorithm name would have been SHA-256 or SHA256 (no
> HMAC).

Good catch. The examples now use AES-128 (BTW, an identifier for AES-128 is not defined in the YANG model in RFC 8177, but it is needed.)

There has been not much energy in TCPM to finalize draft-nayak-tcp-sha2 some years ago. Indeed, we should not use this algorithm in this document. In the meantime, further TCP-AO implementations have emerged. This may open an opportunity to standardize further TCP-AO algorithms. Yet, this discussion seems orthogonal to this YANG model.

> --    Per the link to RFC9235:
> 
>     The following example demonstrates how to model a TCP-AO [RFC5925]
>    configuration for the example in TCP-AO Test Vectors [RFC9235].  The
>    IP addresses and other parameters are taken from the test vectors.
> 
> RFC9235 doesn't use SHA256; and uses KeyID 61 and 84.  Different KeyIDs are
> used in this example.  Which parameters are being used from the test-
> vector?

Good catch. This mismatch was not intended, and we agree that this should be fixed. Yet, unfortunately, when preparing version -08, the authors messed up the corresponding patch, and version -08 still shows the old variant. The current proposal for the example in the next version -09 is:

<!--
This example sets TCP-AO configuration parameters similar to
the examples in RFC 9235.
-->

<key-chains
    xmlns="urn:ietf:params:xml:ns:yang:ietf-key-chain">
  <key-chain>
    <name>ao-config</name>
    <description>"An example for TCP-AO configuration."</description>
    <key>
      <key-id>55</key-id>
      <lifetime>
        <send-lifetime>
          <start-date-time>2017-01-01T00:00:00Z</start-date-time>
          <end-date-time>2017-02-01T00:00:00Z</end-date-time>
        </send-lifetime>
        <accept-lifetime>
          <start-date-time>2016-12-31T23:59:55Z</start-date-time>
          <end-date-time>2017-02-01T00:00:05Z</end-date-time>
        </accept-lifetime>
      </lifetime>
      <crypto-algorithm
	  xmlns:tcp=
	  "urn:ietf:params:xml:ns:yang:ietf-tcp">tcp:aes-128</crypto-algorithm>
      <key-string>
	<keystring>testvector</keystring>
      </key-string>
      <authentication
	  xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp">
	<keychain>ao-config</keychain>
	<ao>
	  <send-id>61</send-id>
	  <recv-id>84</recv-id>
	</ao>
      </authentication>
    </key>
  </key-chain>
</key-chains>

As shown in the example, the suggestion is to use the key ideas from RFC 9235. I'd also simplify the example by using only one entry in the key-chain.

Unless somebody agrees, this example will be used in the next version -09, which will be published soon.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Hilarie Orman for the SECDIR review.
> 
> I concur with the SECDIR observation that "there are no statistics kept for
> authentication failures.  If a shared key falls out of synch, the statistics
> might help detect that."  I appreciate the response
> (https://mailarchive.ietf.org/arch/msg/secdir/BnjVJ7_IgN7mSNaGi3H2ujVYv
> n0/)
> which recommends that this should be generically modeled.  I disagree that
> this
> should be deferred. There is a very specific TCP-level primitive being
> described here and it makes sense to me to provide a corresponding logging
> primitive.

Personally, I don't agree to that observation. For what it is worth, I have replied to this comment already with follow-up questions, as documented in https://mailarchive.ietf.org/arch/msg/tcpm/H0UNpd1Fh-uI6rblHh1895-7iT4/. Unfortunately, I am not aware of any reply.

Yet, that is my personal view only. Adding some counter to make everybody happy may not be a big deal. Therefore, the model now includes in -08 an additional counter:

         leaf auth-failures {	
 	           if-feature authentication;	
 	           type yang:counter64;	
 	           description	
 	             "The number of times that authentication has failed either	
 	              with TCP-AO or MD5.";	
         }

This hopefully sorts out this issue.

Thanks

Michael