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

["[e-mail]" <[e-mail]>]

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
www.strayalpha.com

> On Sep 18, 2022, at 5:31 AM, Natarajan, Venkatesh (HP-Networking) <[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
> 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>
> 
> --------------------------------------
> 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>