[tcpm] Re: Additional Security Algorithms For Use With TCP-AO

["Bonica, Ron" <[e-mail]>]

Yoshifumi,

Thanks for your kind response. I understand the WGs preference for a solution that has a fallback mechanism when the other side doesn't understand extended options.

I believe that we see the following scenarios:


  1.
A TCP session must use extended options on every segment
  2.
A TCP session must use extended options, but only after session establishment
  3.
A TCP session works better with extended options, but also works without them
  4.
A TCP session doesn't need extended options at all

In Scenario 1, capability negotiation isn't an option. The TCP session has no choice other than using extended options in the first segment and risking failure. Draft-bonica is sufficient in this scenario.

In Scenarios 2, 3, and 4, capability negotiation is an option. The TCP endpoints can negotiate extended option capability using a mechanism like that specified in EDO. If both endpoints support extended options, they can proceed to use the mechanism described in draft-bonica.

I propose letting draft-bonica and EDO proceed independently, because we don't know when there will be an urgent need for draft-bonica. However, the authors of these drafts should work together, because in the end state, one draft will provide capability negotiation for the other.

                                                                        Ron


________________________________
From: Yoshifumi Nishida <[e-mail]>
Sent: Tuesday, February 10, 2026 1:28 AM
To: Bonica, Ron <[e-mail]>
Cc: Tony Li <[e-mail]>; Joe Touch <[e-mail]>; Lars Eggert <[e-mail]>; [e-mail] Extensions <[e-mail]>
Subject: Re: [tcpm] Re: Additional Security Algorithms For Use With TCP-AO

Hi Ron,

I don't think the draft is problematic.
I might be wrong, but my personal impression is that people in the community seem to prefer a scheme that has a fall back mechanism rather than 'if the other end doesn't support it, the connection just fails' as a standard.
--
Yoshi

On Sun, Feb 8, 2026 at 1:19 PM Bonica, Ron <[e-mail]<mailto:[e-mail]>> wrote:
Yoshifumi,

Thanks for your consideration.

In the long term, we cannot allow truncation in the SYN. While we can rely on truncation in the short term, we don't know when that short term will end.

We must deploy untruncated MACs before attackers can defeat truncated ones. Given the lead time between standardization and deployment, we should probably begin work today.

Why is the solution proposed in draft-bonica is problematic so long as:


  *
Extended options are never used unless they are used in the first two segments of the session
  *
Application can tolerate session establishment time-out when both parties don't support extended options

Also, could a signaling solution like that proposed in EDO be added later, so that the above mentioned limitations would no longer apply.

I ask this question in sincerity. If I am missing something, please inform me.

                                                                          Ron





________________________________
From: Yoshifumi Nishida <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, February 8, 2026 5:54 AM
To: Bonica, Ron <[e-mail]<mailto:[e-mail]>>
Cc: Tony Li <[e-mail]<mailto:[e-mail]>>; Joe Touch <[e-mail]<mailto:[e-mail]>>; Lars Eggert <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> Extensions <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tcpm] Re: Additional Security Algorithms For Use With TCP-AO

Hi Ron,

Thanks for the comments, I basically support using non truncated MACS. I am just wondering if we can allow to use truncation only for SYN.
In this way, I think we don't need to think about extending SYN option space which is very tricky. In the meantime, I think we might be able to utilize EDO for extending option space in data segments to avoid truncation.
The current drawback of EDO is that it needs to disable GSO/GRO, however, if we use EDO with TCP-AO, this won't be an issue.
--
Yoshi


On Fri, Feb 6, 2026 at 12:47 PM Bonica, Ron <[e-mail]<mailto:[e-mail]>> wrote:
Yoshifumi,

Sorry for the slow response. I have been on holiday.

draft-bonica-tcpm-extended-options and draft-bonica-tcmp-tcp-ao-algs seek to satisfy the following customer requirement:


  *
Authenticate every segment in a long-lived TCP session with algorithms like HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512

The solution is negotiable, but the customer requirement is not.

The customers realize that it is very difficult to increase the size of the TCP Options field. So, they are willing to accept truncated MACS as an expedient (e.g., HMAC-SHA512-128). So, draft-bonica-tcmp-tcp-ao-algs how to use such algorithms with TCP-AO.

However, truncation is only an expedient. Furthermore, this degree of truncation can violate the guidance offered in Section 5 of RFC 2104.

While I have great respect for existing work, I think that the customer requirement is reasonable. I don't think that pushing back on any part of the requirement is a viable option.

                                                Ron




________________________________
From: Yoshifumi Nishida <[e-mail]<mailto:[e-mail]>>
Sent: Monday, February 2, 2026 5:39 AM
To: Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: Joe Touch <[e-mail]<mailto:[e-mail]>>; Lars Eggert <[e-mail]<mailto:[e-mail]>>; Bonica, Ron <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> Extensions <[e-mail]<mailto:[e-mail]>>
Subject: Re: [tcpm] Re: Additional Security Algorithms For Use With TCP-AO



On Sat, Jan 31, 2026 at 5:04 PM Tony Li <[e-mail]<mailto:[e-mail]>> wrote:


> However, it’s been a decade and the former remains in-process and the latter has not been adopted by the WG.


It would seem that there is no interest.

I personally think there are some interests. But, extending option space is not an easy issue for TCP especially for SYN segments.

One thing I am wondering is if this draft can always fit the option into SYN packets without extending option space. This is because extending SYN option space is quite controversial.
OTOH, in my personal opinion, EDO which extends option space for non-SYN segments could proceed it.

The last time I presented Kuniyuki's linux implementation for EDO (https://datatracker.ietf.org/meeting/121/materials/slides-121-tcpm-tcp-extended-data-offset-option<https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/121/materials/slides-121-tcpm-tcp-extended-data-offset-option__;!!NpxR!hx2dG4QMuB9n-YWoo7KXCmEIZbwR1Wwaiiz1Uvz9da6Ug_laE9wjPfCpncAxL0R9e4mCdB5ULs3ajMe3zg$>)
Some folks disagreed proceeding EDO because we will need to turn of GSO/GRO. However, TCP-AO implementation already does the same things.

If the blocking point of EDO draft is disabling GSO/GRO, it seems we have a realistic use case by using it for new TCP-AO even with this drawback.
--
Yoshi