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

[Martin Duke <[e-mail]>]

Can we just post -09 so Roman can clear his DISCUSS?

On Mon, Sep 5, 2022 at 2:10 AM Scharf, Michael <
[e-mail]> wrote:

> 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
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>