Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)

["Natarajan, Venkatesh (HP-Networking)" <[e-mail]>]

Resending my email on top of Joe’s email  to keep the thread in the received order
-Venkatesh

From: Natarajan, Venkatesh (HP-Networking) <[e-mail]>
Date: Saturday, 24 September 2022 at 10:42 PM
To: Leonard Crestez <[e-mail]>, Joe Touch <[e-mail]>
Cc: RFC Errata System <[e-mail]>, Allison Mankin <[e-mail]>, Ron Bonica <[e-mail]>, Martin Duke <[e-mail]>, Zaheduzzaman Sarker <[e-mail]>, Yoshifumi Nishida <[e-mail]>, Michael Tuexen <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Dmitry Safonov <[e-mail]>, Salam Noureddine <[e-mail]>, Francesco Ruggeri <[e-mail]>, Philip Paeps <[e-mail]>
Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)
Hi Leonard

Thanks for looping in the ietf and Arista folks here. I was not sure the ietf members would be interested in a particular OS implementation and hence did you include you in my errata-discussions  with them.

To your statement below;
>>>* accept-ao-mismatch - "This flag indicates whether the receiver should
>>>   accept segments for which the MAC in the incoming TCP AO does not match
>>>  the MAC generated on the receiver"

We initially interpreted the “accept-by-default” in the RFC for a connection when the MKT matches but incoming segment do not contain tcop-ao option. Ofcourse this does not provide any security and is to be configured with caution.
But then later we interpreted as perhaps the intent was to allow for the MKT-Match-But-Keys-Mismatch should be allowed by default and hence raised an Errata ticket for the RFC.

Joe Touch clarified that the RFC text explains for the SYN segments to be accepted for further processing if the MKT matches and obviously the segment would be rejected if the Key-ID or the algorithm does not match to the configured  key-ID/Algo.

So,  for implementation, or for a specific configuration (like for a bgp peer in a peer-group that does not support TCP-AO and perhaps its within the protected network perimeter ) we would need the support for accept-ao-mismatch as how Cisco has implemented (i.e accepting a segment without the tcp-ao option in the tcp header and further responding without the tcp-ao option)

-Venkatesh



From: [e-mail] <[e-mail]>
Date: Saturday, 24 September 2022 at 10:10 PM
To: Leonard Crestez <[e-mail]>
Cc: Natarajan, Venkatesh (HP-Networking) <[e-mail]>, Dmitry Safonov <[e-mail]>, Zaheduzzaman Sarker <[e-mail]>, Francesco Ruggeri <[e-mail]>, Allison Mankin <[e-mail]>, Ron Bonica <[e-mail]>, Michael Tuexen <[e-mail]>, [e-mail] <[e-mail]>, Salam Noureddine <[e-mail]>, RFC Errata System <[e-mail]>
Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)
HI, Leonard,

On Sep 24, 2022, at 6:37 AM, Leonard Crestez <[e-mail]<mailto:[e-mail]>> wrote:

This behavior is not described by RFC and seems to completely defeat the security provided by TCP-AO by accepting all unsigned packets. There does not appear to be any usefulness outside of debugging

It is explicitly designed to allow either side to decide whether TCP-AO is required or optional on incoming connections. The current default is that both sides allow the connection to support legacy mode either when the option isn’t present or when the key fails.

If that’s not desired, either side can set an override (as already mentioned in the paragraph noted in the errata request. If you want the override to be a default on your system, that’s your choice.

Joe



From: Leonard Crestez <[e-mail]>
Date: Saturday, 24 September 2022 at 7:07 PM
To: Joe Touch <[e-mail]>, Natarajan, Venkatesh (HP-Networking) <[e-mail]>
Cc: RFC Errata System <[e-mail]>, Allison Mankin <[e-mail]>, Ron Bonica <[e-mail]>, Martin Duke <[e-mail]>, Zaheduzzaman Sarker <[e-mail]>, Yoshifumi Nishida <[e-mail]>, Michael Tuexen <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Dmitry Safonov <[e-mail]>, Salam Noureddine <[e-mail]>, Francesco Ruggeri <[e-mail]>, Philip Paeps <[e-mail]>
Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)
Hello,

These questions were raised partially in the context of my
implementation for TCP-AO for Linux, which you can find here:

https://lore.kernel.org/netdev/[e-mail]/

I was contacted by the Aruba folks privately regarding my
implementations and it makes sense to also respond publicly.

My implementation will accept unexpected AO signatures by default (as
required by the RFC) and supports an TCP_AUTHOPT_FLAG_REJECT_UNEXPECTED
to reject everything. It aligns with the expected behavior described by
Joe Touch earlier.

My opinion after studying and implementing this RFC is that this
particular quirk of the RFC can't actually be used for anything useful -
at most you go from "Signed SYN / Drop" to "Signed SYN / Unsigned
SYN-ACK / DROP". I don't understand the rationale.

Documentation from cisco describe additional flags, which I believe
Aruba is trying to implement:

* accept-ao-mismatch-connections - "option to accept the connection as
non-TCP AO connection when receives a connection from peer without TCP
AO option".

This behavior is not described by RFC and seems to completely defeat the
security provided by TCP-AO by accepting all unsigned packets. There
does not appear to be any usefulness outside of debugging

* accept-ao-mismatch - "This flag indicates whether the receiver should
accept segments for which the MAC in the incoming TCP AO does not match
the MAC generated on the receiver"

This again seems to be a debug flag which "accepts everything".

My implementation linux does not support these features and I don't
actually see any valid usecase beyond debugging.

I also added some folks from Arista who have a different competing
implementation so that they are aware of this discussion.

--
Regards,
Leonard

On 9/20/22 12:08, Joe Touch wrote:
> Every RFC could have *some* additional discussion that could benefit
> *someone*. There’s no mechanism for that, other than this list, which is
> archived already.
>
> Joe
>
>> On Sep 19, 2022, at 9:49 PM, Natarajan, Venkatesh (HP-Networking)
>> <[e-mail]> wrote:
>>
>> 
>>
>> Thanks Joe for your explanation. My only request at this point would
>> be that while we don’t have the errata published, I think this
>> discussion will benefit others in some way when they try to implement
>> this RFC. Can some excerpt or a summary of this discussion be kept in
>> some form so that this is clear to others as well?
>>
>> -Venkatesh
>>
>> *From: *Joe Touch <[e-mail]>
>> *Date: *Tuesday, 20 September 2022 at 2:44 AM
>> *To: *Natarajan, Venkatesh (HP-Networking) <[e-mail]>
>> *Cc: *RFC Errata System <[e-mail]>, Allison Mankin
>> <[e-mail]>, Ron Bonica <[e-mail]>, Martin Duke
>> <[e-mail]>, Zaheduzzaman Sarker
>> <[e-mail]>, Yoshifumi Nishida
>> <[e-mail]>, Michael Tuexen <[e-mail]>,
>> [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
>> *Subject: *Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)
>>
>> Yes, the connection proceeds past the MKT match step but not the MAC
>> validation step.
>>
>> Joe
>>
>>
>>
>>     On Sep 19, 2022, at 11:34 AM, Natarajan, Venkatesh (HP-Networking)
>>     <[e-mail]> wrote:
>>
>>     
>>
>>     Ok, I think I get what you are saying..
>>
>>     Just to close this with your confirmation,
>>
>>     >>>In case 3 below, the MKT check will accept the segment but the key check will fail in later steps of the processing.
>>
>>     Though the connection will succeed the session will fail beyond
>>     the point of connection establishment as the tcp-ao hash check
>>     will fail??
>>
>>     -Venkatesh
>>
>>     *From: *[e-mail] <[e-mail]>
>>     *Date: *Monday, 19 September 2022 at 8:18 PM
>>     *To: *Natarajan, Venkatesh (HP-Networking)
>>     <[e-mail]>
>>     *Cc: *RFC Errata System <[e-mail]>, Allison
>>     Mankin <[e-mail]>, Ron Bonica <[e-mail]>, Martin
>>     Duke <[e-mail]>, Zaheduzzaman Sarker
>>     <[e-mail]>, Yoshifumi Nishida
>>     <[e-mail]>, Michael Tuexen <[e-mail]>,
>>     [e-mail] <[e-mail]>, [e-mail]
>>     <[e-mail]>
>>     *Subject: *Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)
>>
>>     Hi, Venkatesh,
>>
>>     TCP-AO knows whether to protect a connection at all by the
>>     presence of a match MKT. That’s what the existing text explains.
>>     It says nothing about the key check.
>>
>>     In a protected connection, TCP-AO knows what to do based on
>>     whether the key matches. If an MKT matches but the key fails, the
>>     segment will be dropped and the connection won’t be established.
>>     That’s already explained elsewhere in the doc.
>>
>>     In case 3 below, the MKT check will accept the segment but the key
>>     check will fail in later steps of the processing.
>>
>>     In case 4 below, which side accepts the connection is explained by
>>     the existing text.
>>
>>     In the first sentence, the added  “not matching an MKT” text is
>>     not needed because is that is already what happens when no MKT is
>>     available (a match cannot occur to an item that doesn’t exist).
>>     That doesn’t need over explanation.
>>
>>     The sentence added is incorrect: “In this mode ofoperation, both
>>     the endpoints will not perform TCP-AO validation.”  Each endpoint
>>     makes this decision only for incoming connection establishment;
>>     return packets of connections they initiate with TCP-AO will fail
>>     (due to lack of TCP-AO). There is no clarification of this point
>>     needed.
>>
>>     Joe
>>
>>     —
>>
>>     Dr. Joe Touch, temporal epistemologist
>>
>>     http://www.strayalpha.com<http://www.strayalpha.com>   <http://www.strayalpha.com  >
>>
>>
>>
>>
>>         On Sep 19, 2022, at 5:40 AM, Natarajan, Venkatesh
>>         (HP-Networking) <[e-mail]
>>         <mailto:[e-mail]>> wrote:
>>
>>         Hi Joe,
>>
>>         Sorry I am still not following. I think there is a condition
>>         that is missed. I have captured the permutation/combination in
>>         a table  where both Peer-1 and Peer-2 are TCP-AO capable and
>>         implemented in s/w.
>>
>>         |+-----+-------------------------+-------------------------+--------------------------------+--------------------------------------+|
>>
>>         ||     | Peer-1                  | Peer-2                  |
>>         Expected Behavior              |
>>         Comments                             ||
>>
>>         |+=====+=========================+=========================+================================+======================================+|
>>
>>         ||     |                         |
>>         |
>>         |                                      ||
>>
>>         || 1   | No-TCP-AO configured    | No TCP-AO Configured    |
>>         Vanilla TCP Session            | No TCP-AO but connection
>>         establishes ||
>>
>>         |+-----+-------------------------+-------------------------+--------------------------------+--------------------------------------+|
>>
>>         ||     | TCP-AO Configured with  | TCP-AO Configured with  |
>>         TCP-AO session                 | TCP-AO and connection
>>         establishes.   ||
>>
>>         || 2   | Key1                    | Key1
>>         |
>>         |                                      ||
>>
>>         |+-----+-------------------------+-------------------------+--------------------------------+--------------------------------------+|
>>
>>         ||     | TCP-AO configured with  | TCP-AO configured with  |
>>         Peer-2 will accept connection  | The segments will be accepted
>>         by     ||
>>
>>         ||     | valid Key-1             | valid Key-2             |
>>         from Peer-1 by default for     | default even if there is a
>>         mismatch  ||
>>
>>         ||     | (send-id=recv-id=1)     | (send-id=recv-id=2)     |
>>         mis-match of key               | on
>>         both-ends.                        ||
>>
>>         ||     |                         |
>>         |                                | Agreed, if the default
>>         behaviour at  ||
>>
>>         ||     |                         |                         |
>>         Peer-1 will accept connection  | either peer is changed,
>>         the          ||
>>
>>         ||     |                         |                         |
>>         from Peer-1 by default for     | connection will not be
>>         established.  ||
>>
>>         ||     |                         |                         |
>>         mismatch of key.
>>         |                                      ||
>>
>>         || 3   |                         |                         |
>>                                        | RFC does explain this
>>         point.         ||
>>
>>         |+-----+-------------------------+-------------------------+--------------------------------+--------------------------------------+|
>>
>>         ||     | TCP-AO configured with  | No TCP-AO configured    |
>>         Peer-2 will accept segments    | The point I have made is for
>>         this    ||
>>
>>         ||     | a valid Key-1           |                         |
>>         if it ignores TCP-AO option.   |
>>         condition                            ||
>>
>>         ||     |                         |                         |
>>         Peer-1 will reject segments
>>         |                                      ||
>>
>>         || 4   |                         |                         |
>>         from Peer-2 (No TCP-AO option)
>>         |                                      ||
>>
>>         |+-----+-------------------------+-------------------------+--------------------------------+--------------------------------------+|
>>
>>         If (3) is allowed why not (4). They both have similar
>>          security exposure if not the same.
>>
>>         -Venkatesh
>>
>>         *From:*[e-mail]
>>         <mailto:[e-mail]><[e-mail]
>>         <mailto:[e-mail]>>
>>         *Date:*Sunday, 18 September 2022 at 11:23 PM
>>         *To:*Natarajan, Venkatesh (HP-Networking)
>>         <[e-mail] <mailto:[e-mail]>>
>>         *Cc:*RFC Errata System <[e-mail]
>>         <mailto:[e-mail]>>, Allison Mankin
>>         <[e-mail] <mailto:[e-mail]>>, Ron Bonica
>>         <[e-mail] <mailto:[e-mail]>>, Martin
>>         Duke <[e-mail]
>>         <mailto:[e-mail]>>, Zaheduzzaman Sarker
>>         <[e-mail]
>>         <mailto:[e-mail]>>, Yoshifumi Nishida
>>         <[e-mail] <mailto:[e-mail]>>, Michael
>>         Tuexen <[e-mail]
>>         <mailto:[e-mail]>>,[e-mail]
>>         <mailto:[e-mail]><[e-mail]
>>         <mailto:[e-mail]>>,[e-mail]
>>         <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>
>>         *Subject:*Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)
>>
>>         Hi, Venkatesh,
>>
>>         TCP-AO is designed so that it requires a MKT to operate - even
>>         to discard traffic that lacks TCP-AO headers.
>>
>>         That means that TCP’s behavior doesn’t change UNLESS there’s
>>         an MKT. So anything that matches no MKT is allowed, by default
>>         - even if TCP-AO is in the header.
>>
>>         That’s intentional - it’s “opt-in” on both sides. Let’s look
>>         at the 4 cases, where “client” implies the party initiation
>>         the connection. Assume both sides implement TCP-AO:
>>
>>         - client and server do not have MKTs at all
>>
>>         neither side will match their MKTs, TCP-AO is not used and the
>>         connection proceeds as usual
>>
>>         - client has an MKT that matches, but not the server
>>
>>         Client sends TCP-AO, but server doesn’t check and sends a
>>         SYN-ACK without TCP-AO
>>
>>         Client will now discard any returning packets because they
>>         won’t have TCP-AO
>>
>>         The connection will fail
>>
>>         - client lacks an MKT but server has an MKT that matches
>>
>>         Client sends without TCP-AO, but SYN matches an MKT
>>
>>         Server will drop the SYN because it matches an MKT but fails
>>         the TCP-AO check (it has to - it has no TCP-AO option)
>>
>>         connection will fail
>>
>>         - both sides have MTS that match
>>
>>         everything works
>>
>>         So we don’t need to change the text to handle the case where
>>         the endpoints differ in whether they want to use TCP-AO on a
>>         connection.
>>
>>         The “default accept” is per side, but the total effect is
>>         “default deny unless both sides use it and have the right keys”.
>>
>>         Joe
>>
>>         —
>>
>>         Dr. Joe Touch, temporal epistemologist
>>
>>         http://www.strayalpha.com<http://www.strayalpha.com>   <http://www.strayalpha.com/  >
>>
>>
>>
>>
>>
>>             On Sep 18, 2022, at 5:31 AM, Natarajan, Venkatesh
>>             (HP-Networking) <[e-mail]
>>             <mailto:[e-mail]>> wrote:
>>
>>             Hi Joe,
>>
>>             Thank you for reviewing the Errata submission.
>>
>>             The whole point of having a default-accept for a MKT
>>             mismatch is to allow a mismatch-key-TCP-AO connection
>>             establishment even if the TCP-AO was the intended use.  If
>>             only one endpoint between the two is configured for TCP-AO
>>             , then also it is the same condition where there is no
>>             authentication. I do not understand the differentiation
>>             that is being brought out by the 7.3 section in the RFC
>>             for allowing a mismatch-key tcp-ao and when the tcp-ao
>>             option itself is not present. How is one different from
>>             the other in term of security. Both are offering
>>             unsecured/unprotected connection.
>>
>>             What do you think is the reason for a unsecure connection
>>             be allowed by default?  I can reason to some extent that
>>             such a behavior be implemented iff there is a transition
>>             period for  Non-TCP-AO to TCP-AO and say the server has
>>             migrated to TCP-AO but some of the clients are yet to be
>>             upgraded/migrated to use TCP-AO. Its in this mode that the
>>             acceptance of a connection from a non-tcp-ao client
>>             (segment having no-tcp-oa option) even makes sense.
>>
>>             -Venkatesh
>>
>>             *From:*[e-mail]
>>             <mailto:[e-mail]><[e-mail]
>>             <mailto:[e-mail]>>
>>             *Date:*Sunday, 18 September 2022 at 5:33 AM
>>             *To:*RFC Errata System <[e-mail]
>>             <mailto:[e-mail]>>
>>             *Cc:*Dr. Joe Touch <[e-mail] <mailto:[e-mail]>>,
>>             Allison Mankin <[e-mail] <mailto:[e-mail]>>,
>>             Ron Bonica <[e-mail]
>>             <mailto:[e-mail]>>, Martin Duke
>>             <[e-mail]
>>             <mailto:[e-mail]>>, Zaheduzzaman Sarker
>>             <[e-mail]
>>             <mailto:[e-mail]>>, Yoshifumi
>>             Nishida <[e-mail] <mailto:[e-mail]>>,
>>             Michael Tuexen <[e-mail]
>>             <mailto:[e-mail]>>,[e-mail]
>>             <mailto:[e-mail]><[e-mail]
>>             <mailto:[e-mail]>>, Natarajan, Venkatesh
>>             (HP-Networking) <[e-mail]
>>             <mailto:[e-mail]>>,[e-mail]
>>             <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>
>>             *Subject:*Re: [tcpm] [Technical Errata Reported] RFC5925
>>             (7135)
>>
>>             Hi, all,
>>
>>             I disagree with this errata.
>>
>>             The decision is based on whether the segments match an
>>             MKT. If TCP-AO is required, an MKT would have been
>>             configured; packets with the option would match the MKT
>>             and proceed. Packets without the option would not match
>>             the MKT - because an MKT requires info in the option.
>>
>>             Recommend reject.
>>
>>             Joe
>>
>>             —
>>
>>             Dr. Joe Touch, temporal epistemologist
>>
>>             http://www.strayalpha.com<http://www.strayalpha.com>   <http://www.strayalpha.com/  >
>>
>>
>>
>>
>>                 On Sep 16, 2022, at 1:31 AM, RFC Errata System
>>                 <[e-mail]
>>                 <mailto:[e-mail]>> wrote:
>>
>>                 The following errata report has been submitted for
>>                 RFC5925,
>>                 "The TCP Authentication Option".
>>
>>                 --------------------------------------
>>                 You may review the report below and at:
>>                 https://www.rfc-editor.org/errata/eid7135<https://www.rfc-editor.org/errata/eid7135>
>>                 <https://www.rfc-editor.org/errata/eid7135  >
>>
>>                 --------------------------------------
>>                 Type: Technical
>>                 Reported by: Venkatesh Natarajan
>>                 <[e-mail]
>>                 <mailto:[e-mail]>>
>>
>>                 Section: 7.3
>>
>>                 Original Text
>>                 -------------
>>
>>
>>                         A TCP-AO implementation MUST allow for
>>                         configuration of the
>>
>>                   behavior of segments with TCP-AO but that do not
>>                 match an MKT.  The
>>                   initial default of this configuration SHOULD be to
>>                 silently accept
>>                   such connections.  If this is not the desired case,
>>                 an MKT can be
>>                   included to match such connections, or the
>>                 connection can indicate
>>                   that TCP-AO is required.  Alternately, the
>>                 configuration can be
>>                   changed to discard segments with the AO option not
>>                 matching an MKT.
>>
>>                 Corrected Text
>>                 --------------
>>
>>
>>                         A TCP-AO implementation MUST allow for
>>                         configuration of the
>>
>>                   behavior of segments with TCP-AO but that do not
>>                 match any MKT or
>>                   no MKT is available. The initial default of this
>>                 configuration
>>                   SHOULD be to silently accept such connections. In
>>                 this mode of
>>                   operation, both the endpoints will not perform
>>                 TCP-AO validation.
>>                   If this is not the desired case, an MKT can be
>>                 included to match such
>>                   connections, or the connection can indicate that
>>                 TCP-AO is required.
>>                   Alternately, the configuration can be changed to
>>                 discard segments
>>                   with the AO option not matching an MKT.
>>
>>                 Notes
>>                 -----
>>                 The RFC does not clearly draw out the distinction
>>                 between treatment of segments with TCP-AO and without
>>                 TCP-AO option.
>>                 Note that in the case of MKT mismatch as per existing
>>                 RFC text, if either endpoint does TCP-AO validation,
>>                 the session would not get established.
>>
>>                 Instructions:
>>                 -------------
>>                 This erratum is currently posted as "Reported". If
>>                 necessary, please
>>                 use "Reply All" to discuss whether it should be
>>                 verified or
>>                 rejected. When a decision is reached, the verifying party
>>                 can log in to change the status and edit the report,
>>                 if necessary.
>>
>>                 --------------------------------------
>>                 RFC5925 (draft-ietf-tcpm-tcp-auth-opt-11)
>>                 --------------------------------------
>>                 Title               : The TCP Authentication Option
>>                 Publication Date    : June 2010
>>                 Author(s)           : J. Touch, A. Mankin, R. Bonica
>>                 Category            : PROPOSED STANDARD
>>                 Source              : TCP Maintenance and Minor Extensions
>>                 Area                : Transport
>>                 Stream              : IETF
>>                 Verifying Party     : IESG
>>
>>                 _______________________________________________
>>                 tcpm mailing list
>>                 [e-mail] <mailto:[e-mail]>
>>                 https://www.ietf.org/mailman/listinfo/tcpm<https://www.ietf.org/mailman/listinfo/tcpm>
>>                 <https://www.ietf.org/mailman/listinfo/tcpm  >
>>