From nobody Tue Sep 20 08:18:46 2022 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8C2C1522C7 for ; Tue, 20 Sep 2022 02:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrE2te_nWsTd for ; Tue, 20 Sep 2022 02:09:10 -0700 (PDT) Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FF5C1522B0 for ; Tue, 20 Sep 2022 02:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ucPHNpeumu0BBhupoV88QDwJgBYhl35SugzGXoUSX/o=; b=cNHMCBapJNYaMF4WaXP/+pt9z1 c2bw8wzQqF5XMWJ6FD3lc3RVqi1Y5B0bw4KYuZhI5Jtu7SnjWjHMbFhtfWaxRDS28XNLFPbtXyWfE uz1HANFpMHCjSIFsDyKUp+9fPrdegS8UJaKqMqYIEEHTezdmdqaSOjPAObJi1435cIm2js14C0e1A 7XocgYEYsLaOWpjiCuzUlUrp2pbKnPG1gQM7iyu8ehpZ6SOyBO0JvbToMeGA2I+lbLX5UAbLYqIsr 2MuNLuMOH7DFruL9/LadZAhajLGUJIgV5CEe8tj1WkUkxklxjRX0mZOtdw+zZJhjwOhG0JnrIDSvZ h0ISPruQ==; Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:49665 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oaZEq-006BUF-W7; Tue, 20 Sep 2022 05:08:27 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-AE12C83C-F917-4872-BE46-9030FAE12E55 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: Date: Tue, 20 Sep 2022 02:08:18 -0700 Cc: RFC Errata System , Allison Mankin , Ron Bonica , Martin Duke , Zaheduzzaman Sarker , Yoshifumi Nishida , Michael Tuexen , ianswett@google.com, tcpm@ietf.org Message-Id: <7C3A53C8-7D86-410A-BBC5-737546127E14@strayalpha.com> References: To: "Natarajan, Venkatesh (HP-Networking)" X-Mailer: iPad Mail (19G82) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-Mailman-Approved-At: Tue, 20 Sep 2022 08:18:40 -0700 Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2022 09:09:15 -0000 --Apple-Mail-AE12C83C-F917-4872-BE46-9030FAE12E55 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Every RFC could have *some* additional discussion that could benefit *someon= e*. There=E2=80=99s no mechanism for that, other than this list, which is ar= chived already. Joe > On Sep 19, 2022, at 9:49 PM, Natarajan, Venkatesh (HP-Networking) wrote: >=20 > =EF=BB=BF > Thanks Joe for your explanation. My only request at this point would be th= at while we don=E2=80=99t have the errata published, I think this discussion= will benefit others in some way when they try to implement this RFC. Can so= me excerpt or a summary of this discussion be kept in some form so that this= is clear to others as well? > =20 > -Venkatesh > =20 > From: Joe Touch > Date: Tuesday, 20 September 2022 at 2:44 AM > To: Natarajan, Venkatesh (HP-Networking) > Cc: RFC Errata System , Allison Mankin , Ron Bonica , Martin Duke , Zaheduzzaman Sarker , Yoshifumi Nis= hida , Michael Tuexen , ianswett@= google.com , tcpm@ietf.org > Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135) >=20 > Yes, the connection proceeds past the MKT match step but not the MAC valid= ation step.=20 > =20 > Joe >=20 >=20 > On Sep 19, 2022, at 11:34 AM, Natarajan, Venkatesh (HP-Networking) wrote: >=20 > =EF=BB=BF > Ok, I think I get what you are saying.. > =20 > Just to close this with your confirmation, > >>>In case 3 below, the MKT check will accept the segment but the key chec= k will fail in later steps of the processing. > Though the connection will succeed the session will fail beyond the point o= f connection establishment as the tcp-ao hash check will fail?? > =20 > -Venkatesh > =20 > From: touch@strayalpha.com > Date: Monday, 19 September 2022 at 8:18 PM > To: Natarajan, Venkatesh (HP-Networking) > Cc: RFC Errata System , Allison Mankin , Ron Bonica , Martin Duke , Zaheduzzaman Sarker , Yoshifumi Nis= hida , Michael Tuexen , ianswett@= google.com , tcpm@ietf.org > Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135) >=20 > Hi, Venkatesh, > =20 > TCP-AO knows whether to protect a connection at all by the presence of a m= atch MKT. That=E2=80=99s what the existing text explains. It says nothing ab= out the key check. > =20 > In a protected connection, TCP-AO knows what to do based on whether the ke= y matches. If an MKT matches but the key fails, the segment will be dropped a= nd the connection won=E2=80=99t be established. That=E2=80=99s already expla= ined elsewhere in the doc. > =20 > In case 3 below, the MKT check will accept the segment but the key check w= ill fail in later steps of the processing. > =20 > In case 4 below, which side accepts the connection is explained by the exi= sting text.=20 > =20 > In the first sentence, the added =E2=80=9Cnot matching an MKT=E2=80=9D te= xt is not needed because is that is already what happens when no MKT is avai= lable (a match cannot occur to an item that doesn=E2=80=99t exist). That doe= sn=E2=80=99t need over explanation. > =20 > The sentence added is incorrect: =E2=80=9CIn this mode of operation, both t= he endpoints will not perform TCP-AO validation.=E2=80=9D Each endpoint mak= es this decision only for incoming connection establishment; return packets o= f connections they initiate with TCP-AO will fail (due to lack of TCP-AO). T= here is no clarification of this point needed. > =20 > Joe > =E2=80=94 > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com >=20 >=20 >=20 > On Sep 19, 2022, at 5:40 AM, Natarajan, Venkatesh (HP-Networking) wrote: > =20 > Hi Joe, > =20 > Sorry I am still not following. I think there is a condition that is misse= d. 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. > =20 > +-----+-------------------------+-------------------------+---------------= -----------------+--------------------------------------+ > | | Peer-1 | Peer-2 | Expected Behav= ior | Comments | > +=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + > | | | | = | | > | 1 | No-TCP-AO configured | No TCP-AO Configured | Vanilla TCP Se= ssion | 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 ac= cept 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=3Drecv-id=3D1) | (send-id=3Drecv-id=3D2) | mis-ma= tch of key | on both-ends. | > | | | | = | Agreed, if the default behaviour at | > | | | | Peer-1 will ac= cept connection | either peer is changed, the | > | | | | from Peer-1 by= default for | connection will not be established. | > | | | | mismatch of ke= y. | | > | 3 | | | = | RFC does explain this point. | > +-----+-------------------------+-------------------------+---------------= -----------------+--------------------------------------+ > | | TCP-AO configured with | No TCP-AO configured | Peer-2 will ac= cept segments | The point I have made is for this | > | | a valid Key-1 | | if it ignores T= CP-AO option. | condition | > | | | | Peer-1 will re= ject segments | | > | 4 | | | from Peer-2 (N= o TCP-AO option) | | > +-----+-------------------------+-------------------------+---------------= -----------------+--------------------------------------+ > =20 > =20 > If (3) is allowed why not (4). They both have similar security exposure i= f not the same. > =20 > -Venkatesh > =20 > From: touch@strayalpha.com > Date: Sunday, 18 September 2022 at 11:23 PM > To: Natarajan, Venkatesh (HP-Networking) > Cc: RFC Errata System , Allison Mankin , Ron Bonica , Martin Duke , Zaheduzzaman Sarker , Yoshifumi Nis= hida , Michael Tuexen , ianswett@= google.com , tcpm@ietf.org > Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135) >=20 > Hi, Venkatesh, > =20 > TCP-AO is designed so that it requires a MKT to operate - even to discard t= raffic that lacks TCP-AO headers.=20 > =20 > That means that TCP=E2=80=99s behavior doesn=E2=80=99t change UNLESS there= =E2=80=99s an MKT. So anything that matches no MKT is allowed, by default - e= ven if TCP-AO is in the header. > =20 > That=E2=80=99s intentional - it=E2=80=99s =E2=80=9Copt-in=E2=80=9D on both= sides. Let=E2=80=99s look at the 4 cases, where =E2=80=9Cclient=E2=80=9D im= plies the party initiation the connection. Assume both sides implement TCP-A= O: > - client and server do not have MKTs at all > neither side will match their MKTs, TCP-AO is not used and the connection p= roceeds as usual > - client has an MKT that matches, but not the server > Client sends TCP-AO, but server doesn=E2=80=99t check and sends a SYN-ACK w= ithout TCP-AO > Client will now discard any returning packets because they won=E2=80=99t h= ave 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 ch= eck (it has to - it has no TCP-AO option) > connection will fail > - both sides have MTS that match > everything works > =20 > So we don=E2=80=99t need to change the text to handle the case where the e= ndpoints differ in whether they want to use TCP-AO on a connection. > =20 > The =E2=80=9Cdefault accept=E2=80=9D is per side, but the total effect is =E2= =80=9Cdefault deny unless both sides use it and have the right keys=E2=80=9D= . > =20 > Joe > =20 > =E2=80=94 > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com >=20 >=20 >=20 >=20 > On Sep 18, 2022, at 5:31 AM, Natarajan, Venkatesh (HP-Networking) wrote: > =20 > Hi Joe, > =20 > Thank you for reviewing the Errata submission. > =20 > 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 int= ended use. If only one endpoint between the two is configured for TCP-AO , t= hen 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 it= self is not present. How is one different from the other in term of security= . Both are offering unsecured/unprotected connection. > =20 > What do you think is the reason for a unsecure connection be allowed by de= fault? I can reason to some extent that such a behavior be implemented iff t= here 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 t= o use TCP-AO. Its in this mode that the acceptance of a connection from a no= n-tcp-ao client (segment having no-tcp-oa option) even makes sense. > =20 > -Venkatesh > =20 > From: touch@strayalpha.com > Date: Sunday, 18 September 2022 at 5:33 AM > To: RFC Errata System > Cc: Dr. Joe Touch , Allison Mankin , Ron Bo= nica , Martin Duke , Zaheduzza= man Sarker , Yoshifumi Nishida , Michael Tuexen , ianswett@google.com , Natarajan, Venkatesh (HP-Networking) , tcpm@ietf.org > Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135) >=20 > Hi, all, > =20 > I disagree with this errata. > =20 > The decision is based on whether the segments match an MKT. If TCP-AO is r= equired, an MKT would have been configured; packets with the option would ma= tch the MKT and proceed. Packets without the option would not match the MKT -= because an MKT requires info in the option. > =20 > Recommend reject. > =20 > Joe > =20 > =E2=80=94 > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com >=20 >=20 >=20 >=20 > On Sep 16, 2022, at 1:31 AM, RFC Errata System = wrote: > =20 > The following errata report has been submitted for RFC5925, > "The TCP Authentication Option". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7135 >=20 > -------------------------------------- > Type: Technical > Reported by: Venkatesh Natarajan >=20 > Section: 7.3 >=20 > Original Text > ------------- >=20 >=20 >=20 > 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. >=20 > Corrected Text > -------------- >=20 >=20 >=20 > A TCP-AO implementation MUST allow for configuration of the > behavior of segments with TCP-AO but that do not match any MKT or=20 > no MKT is available. The initial default of this configuration=20 > SHOULD be to silently accept such connections. In this mode of=20 > 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=20= > connections, or the connection can indicate that TCP-AO is required.=20 > Alternately, the configuration can be changed to discard segments > with the AO option not matching an MKT. >=20 > Notes > ----- > The RFC does not clearly draw out the distinction between treatment of seg= ments with TCP-AO and without TCP-AO option. > Note that in the case of MKT mismatch as per existing RFC text, if either e= ndpoint does TCP-AO validation, the session would not get established. >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > 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 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > =20 --Apple-Mail-AE12C83C-F917-4872-BE46-9030FAE12E55 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Eve= ry RFC could have *some* additional discussion that could benefit *someone*.= There=E2=80=99s no mechanism for that, other than this list, which is archi= ved already.

Joe

On Sep 19, 2022, at 9:49 PM, Natara= jan, Venkatesh (HP-Networking) <venkatesh.natarajan@hpe.com> wrote:
=EF=BB=BF=

Thanks Joe for your e= xplanation. My only request at this point would be that while we don=E2=80=99= t have the errata published, I think this discussion will benefit others in s= ome way when they try to implement this RFC. Can some excerpt or a summary of this discussion be kept in some form s= o that this is clear to others as well?

 

-Venkatesh

 

From: Joe Touch <touch@= strayalpha.com>
Date: Tuesday, 20 September 2022 at 2:44 AM
To: Natarajan, Venkatesh (HP-Networking) <venkatesh.natarajan@hpe.= com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Allison Mank= in <mankin@psg.com>, Ron Bonica <rbonica@juniper.net>, Martin Du= ke <martin.h.duke@gmail.com>, Zaheduzzaman Sarker <zaheduzzaman.sar= ker@ericsson.com>, Yoshifumi Nishida <nsd.ietf@gmail.com>, Michael Tuexen <tuexen@fh-muenster.de>, ianswett@google.com <iansw= ett@google.com>, tcpm@ietf.org <tcpm@ietf.org>
Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)

Yes, the connection p= roceeds past the MKT match step but not the MAC validation step. <= /o:p>

 

Joe



On Sep 19, 2022, at 11:34 AM, Natarajan, Venkatesh (HP-Networking= ) <venkatesh.natarajan@hpe.com> wrote:

=EF=BB=BF

Ok, I think I get wh= at you are saying..

 

Just to close this w= ith 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 connectio= n will succeed the session will fail beyond the point of connection establis= hment as the tcp-ao hash check will fail??

 

-Venkatesh

 

From: touch@strayalpha.com= <touch@strayalpha.com>
Date: Monday, 19 September 2022 at 8:18 PM
To: Natarajan, Venkatesh (HP-Networking) <venkatesh.natarajan@hpe.= com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Allison Mank= in <mankin@psg.com>, Ron Bonica <rbonica@juniper.net>, Martin Du= ke <martin.h.duke@gmail.com>, Zaheduzzaman Sarker <Zaheduzzaman.Sar= ker@ericsson.com>, Yoshifumi Nishida <nsd.ietf@gmail.com>, Michael Tuexen <tuexen@fh-muenster.de>, ianswett@google.com <iansw= ett@google.com>, tcpm@ietf.org <tcpm@ietf.org>
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=E2=80=99= s what the existing text explains. It says nothing about the key check.

 

In a protected conne= ction, TCP-AO knows what to do based on whether the key matches. If an MKT m= atches but the key fails, the segment will be dropped and the connection won= =E2=80=99t be established. That=E2=80=99s 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 step= s of the processing.

 

In case 4 below, whi= ch side accepts the connection is explained by the existing text. 

 

In the first sentenc= e, the added  =E2=80=9Cnot matching an MKT=E2=80=9D text is not needed b= ecause is that is already what happens when no MKT is available (a match can= not occur to an item that doesn=E2=80=99t exist). That doesn=E2=80=99t need over explanation.

 

The sentence added i= s incorrect: =E2=80=9CIn this mode of&= nbsp;operation, both the endpoints will not perform TCP-AO validation= .=E2=80=9D  Each endpoint makes this decision only for incoming connection establishment; return packets of connections they initiate with T= CP-AO will fail (due to lack of TCP-AO). There is no clarification of this p= oint needed.

 

Joe

=E2=80=94=

Dr. Joe T= ouch, temporal epistemologist




On Sep 19, 2022, at 5= :40 AM, Natarajan, Venkatesh (HP-Networking) <venkatesh.natarajan@hpe.com> wrote:

 

Hi Joe,<= /o:p>

 

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 T= CP-AO capable and implemented in s/w.

 

+-----+-=
------------------------+-------------------------+-------------------------=
-------+--------------------------------------+

| &=
nbsp;   | Peer-1        &n=
bsp;         | Peer-2  &nb=
sp;            &=
nbsp;  | Expected Behavior        &n=
bsp;     | Comments     &n=
bsp;            =
           |=



+=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+


| &=
nbsp;   |         &nb=
sp;            &=
nbsp;  |          &nb=
sp;            &=
nbsp; |           &nb=
sp;            &=
nbsp;       |     &nb=
sp;            &=
nbsp;            =
;       |


| 1 =
;  | No-TCP-AO configured    | No TCP-AO Configured =
;   | Vanilla TCP Session       =
;     | No TCP-AO but connection establishes |


+-----+-=
------------------------+-------------------------+-------------------------=
-------+--------------------------------------+

| &=
nbsp;   | TCP-AO Configured with  | TCP-AO Configured with&nb=
sp; | TCP-AO session         &n=
bsp;       | TCP-AO and connection establishes=
.   |


| 2 =
;  | Key1          &n=
bsp;         | Key1   =
;            &nb=
sp;    |         =
;            &nb=
sp;          |   =
;            &nb=
sp;            &=
nbsp;         |


+-----+-=
------------------------+-------------------------+-------------------------=
-------+--------------------------------------+

| &=
nbsp;   | TCP-AO configured with  | TCP-AO configured with&nb=
sp; | Peer-2 will accept connection  | The segments will be accepted by=
     |


| &=
nbsp;   | valid Key-1       &nb=
sp;     | valid Key-2      =
;       | from Peer-1 by default for &nbs=
p;   | default even if there is a mismatch  |


| &=
nbsp;   | (send-id=3Drecv-id=3D1)     | (send-=
id=3Drecv-id=3D2)     | mis-match of key  &nbs=
p;            | on bo=
th-ends.           &n=
bsp;            |


| &=
nbsp;   |         &nb=
sp;            &=
nbsp;  |          &nb=
sp;            &=
nbsp; |           &nb=
sp;             =
       | Agreed, if the default behaviour=
 at  |


| &=
nbsp;   |         &nb=
sp;            &=
nbsp;  |          &nb=
sp;            &=
nbsp; | Peer-1 will accept connection  | either peer is changed, the&nb=
sp;         |


| &=
nbsp;   |         &nb=
sp;            &=
nbsp;  |          &nb=
sp;            &=
nbsp; | from Peer-1 by default for     | connection will=
 not be established.  |


| &=
nbsp;   |         &nb=
sp;            &=
nbsp;  |          &nb=
sp;            &=
nbsp; | mismatch of key.        &nbs=
p;      |       =
            &nbs=
p;            &n=
bsp;     |


| 3 =
;  |           &=
nbsp;            =
; |            &=
nbsp;            | &n=
bsp;            =
            &nbs=
p;     | RFC does explain this point.  &n=
bsp;      |


+-----+-=
------------------------+-------------------------+-------------------------=
-------+--------------------------------------+

| &=
nbsp;   | TCP-AO configured with  | No TCP-AO configured =
;   | Peer-2 will accept segments    | The point I h=
ave made is for this    |


| &=
nbsp;   | a valid Key-1       &=
nbsp;   |         &nb=
sp;            &=
nbsp;  | if it ignores TCP-AO option.   | condition &nbs=
p;            &n=
bsp;            =
 |


| &=
nbsp;   |         &nb=
sp;            &=
nbsp;  |           &n=
bsp;            =
 | Peer-1 will reject segments    |   &nb=
sp;            &=
nbsp;            =
;         |=



| 4 =
;  |           &=
nbsp;            =
; |            &=
nbsp;            | fr=
om Peer-2 (No TCP-AO option) |       &nbs=
p;            &n=
bsp;            =
     |


+-----+-=
------------------------+-------------------------+-------------------------=
-------+--------------------------------------+



 






 






If (3) is allowed wh=
y not (4). They both have similar  security exposure if not the same.






 






-Venkatesh






 






From: touch@strayalpha.com <touch@strayalpha.com>
Date: Sunday, 18 Se=
ptember 2022 at 11:23 PM

To: Natarajan, Venk=
atesh (HP-Networking) <ven=
katesh.natarajan@hpe.com>

Cc: RFC Errata Syst=
em <rfc-editor@rfc-editor.or=
g>, Allison Mankin <mankin@psg.c=
om>, Ron Bonica <rbonica@ju=
niper.net>,
 Martin Duke <martin.h.duke@gm=
ail.com>, Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>, Yoshifumi Nishida=
 <nsd.ietf@gmail.com>,
 Michael Tuexen <tuexen@fh-muens=
ter.de>, ianswett@google.com <ianswe=
tt@google.com>, tcpm@ietf.org <tcpm@ietf.org&=
gt;

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






Hi, Venkatesh,








 










TCP-AO is designed s=
o that it requires a MKT to operate - even to discard traffic that lacks TCP=
-AO headers. 










 










That means that TCP=E2=
=80=99s behavior doesn=E2=80=99t change UNLESS there=E2=80=99s an MKT. So an=
ything that matches no MKT is allowed, by default - even if TCP-AO is in the=
 header.










 










That=E2=80=99s inten=
tional - it=E2=80=99s =E2=80=9Copt-in=E2=80=9D on both sides. Let=E2=80=99s l=
ook at the 4 cases, where =E2=80=9Cclient=E2=80=9D implies the party initiat=
ion the connection. Assume both sides implement TCP-AO:









- client and server d=
o not have MKTs at all










neither side will ma=
tch their MKTs, TCP-AO is not used and the connection proceeds as usual=











- client has an MKT t=
hat matches, but not the server










Client sends TCP-AO,=
 but server doesn=E2=80=99t check and sends a SYN-ACK without TCP-AO<=
o:p>










Client will now disc=
ard any returning packets because they won=E2=80=99t have TCP-AO=











The connection will f=
ail










- client lacks an MK=
T 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 ha=
s no TCP-AO option)










connection will fail=











- both sides have MT=
S that match










everything works










 










So we don=E2=80=99t n=
eed to change the text to handle the case where the endpoints differ in whet=
her they want to use TCP-AO on a connection.










 










The =E2=80=9Cdefault=
 accept=E2=80=9D is per side, but the total effect is =E2=80=9Cdefault deny u=
nless both sides use it and have the right keys=E2=80=9D.<=
/p>









 










Joe










 












=E2=80=94








Dr. Joe Touch, tempo=
ral epistemologist




































On Sep 18, 2022, at 5=
:31 AM, Natarajan, Venkatesh (HP-Networking) <venkatesh.natara=
jan@hpe.com>
 wrote:








 










Hi Joe,<=
/o:p>








 








Thank you for review=
ing the Errata submission.








 








The whole point of h=
aving a default-accept for a MKT mismatch is to allow a mismatch-key-TCP-AO c=
onnection establishment even if the TCP-AO was the intended use.  If on=
ly one endpoint between the two is configured
 for TCP-AO , then also it is the same condition where there is no authentic=
ation. I do not understand the differentiation that is being brought out by t=
he 7.3 section in the RFC for allowing a mismatch-key tcp-ao and when the tc=
p-ao option itself is not present.
 How is one different from the other in term of security. Both are offering u=
nsecured/unprotected connection.








 








What do you think is=
 the reason for a unsecure connection be allowed by default?  I can rea=
son to some extent that such a behavior be implemented iff there is a transi=
tion period for  Non-TCP-AO to TCP-AO
 and say the server has migrated to TCP-AO but some of the clients are yet t=
o be upgraded/migrated to use TCP-AO. Its in this mode that the acceptance o=
f a connection from a non-tcp-ao client (segment having no-tcp-oa option) ev=
en makes sense.








 








-Venkatesh








 






From: touch@strayalpha.com <touch@strayalpha.com>

Date: Sunday, 18 Se=
ptember 2022 at 5:33 AM

To: RFC Errata Syst=
em <rfc-editor@rfc-editor.org>

Cc: Dr. Joe Touch &=
lt;=
touch@isi.edu>, Allison Manki=
n <mankin@psg.com>,
 Ron Bonica <rbonica@juniper.net>, Martin Duke <martin.h.duke@gmail.com>,
 Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>, Yoshifumi Nishida <=
nsd.i=
etf@gmail.com>,
 Michael Tuexen <tuexen@fh-muenster.de>, ian=
swett@google.com &=
lt;ianswett@google.com>,
 Natarajan, Venkatesh (HP-Networking) <venkatesh.natarajan@hpe=
.com>, tcpm@ietf.org <tcpm@ietf.org=
>

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








Hi, all,=











 












I disagree with this=
 errata.












 












The decision is base=
d on whether the segments match an MKT. If TCP-AO is required, an MKT would h=
ave 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












 














=E2=80=94












Dr. Joe Touch, tempo=
ral epistemologist










































On Sep 16, 2022, at 1=
:31 AM, RFC Errata System <rfc-editor@rfc-editor.org<=
span style=3D"font-size:11.0pt">> 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



--------------------------------------

Type: Technical

Reported by: Venkatesh Natarajan <venkatesh.natarajan@hpe.com<=
/span>>



Section: 7.3



Original Text

-------------




















A TCP-AO implementat=
ion MUST allow for configuration of the














  behavior of segments with TCP-AO but that do not matc=
h an MKT.  The

  initial default of this configuration SHOULD be to silently acce=
pt

  such connections.  If this is not the desired case, an MKT c=
an be

  included to match such connections, or the connection can indica=
te

  that TCP-AO is required.  Alternately, the configuration ca=
n be

  changed to discard segments with the AO option not matching an M=
KT.



Corrected Text

--------------




















A TCP-AO implementat=
ion 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 requi=
red. 

  Alternately, the configuration can be changed to discard segment=
s

  with the AO option not matching an MKT.



Notes

-----

The RFC does not clearly draw out the distinction between treatment of segme=
nts with TCP-AO and without TCP-AO option.

Note that in the case of MKT mismatch as per existing RFC text, if either en=
dpoint 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            &nbs=
p;  : The TCP Authentication Option

Publication Date    : June 2010

Author(s)           : J. T=
ouch, A. Mankin, R. Bonica

Category            :=
 PROPOSED STANDARD

Source            &nb=
sp; : TCP Maintenance and Minor Extensions

Area             =
;   : Transport

Stream            &nb=
sp; : IETF

Verifying Party     : IESG



_______________________________________________

tcpm mailing list

tcp=
m@ietf.org

https://www.ietf.org/mailman/listinfo/tcpm

 

= --Apple-Mail-AE12C83C-F917-4872-BE46-9030FAE12E55--