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

[Joe Touch <[e-mail]>]

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 of operation, 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" rel="nofollow">www.strayalpha.com

On Sep 19, 2022, at 5:40 AM, Natarajan, Venkatesh (HP-Networking) <[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] <[e-mail]>
Date: Sunday, 18 September 2022 at 11:23 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 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/" rel="nofollow">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] <[e-mail]>
Date: Sunday, 18 September 2022 at 5:33 AM
To: RFC Errata System <[e-mail]>
Cc: Dr. Joe Touch <[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]>, Natarajan, Venkatesh (HP-Networking) <[e-mail]>, [e-mail] <[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/" rel="nofollow">www.strayalpha.com

On Sep 16, 2022, at 1:31 AM, RFC Errata System <[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" rel="nofollow">https://www.rfc-editor.org/errata/eid7135

--------------------------------------
Type: Technical
Reported by: Venkatesh Natarajan <[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]
https://www.ietf.org/mailman/listinfo/tcpm" rel="nofollow">https://www.ietf.org/mailman/listinfo/tcpm