Subject: [tcpm] Roman Danyliw's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 22 Sep 2021 20:59:46 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-tcpm-rfc793bis-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Kyle Rose for the SECDIR review.

I support Ben, Lars, Warren and Zahed’s DISCUSS positions.

** Appendix A.1 and the shepherd write-up which explains why the antiquated
text around “security compartments” for multi-level systems is still in this
draft.  It’s disappointing that there was no prior IETF consensus action to
establish the basis of pruning it.  My suggested addition for Appendix A.1
would be to make a much clearer statement than “the state of IP security
options that may be used by MLS systems is not as clean”.  It isn’t clear what
is meant by “clean” – is it intended to say that it is not in fact used?

** Section 3.1. Per “[TCP Option]; Options#Size == (DOffset-5)*32;”, I found
this notation confusing. What does the “#” in “Options#Size” indicate?

** Section 3.4.  Per “There are security issues that result if an off-path
attacker is able to predict or guess ISN values”, a reference might be helpful
for this statement.  Perhaps [41] or [Morris185] from [41].

** Section 3.9.2 and 3.9.2.1 The text here discusses various IP options like
timestamp, record route and source routing.  Either in this section or in the
Security Considerations the security implications of these options should be
highlights.  Specifically, Section 4.3 – 4.5 of RFC7126 outline these security
issues and has normative guidance to treat these packets as default drop.

** Section 7.  Recommend being more precise on the lack of security services:

OLD
but there are no built-in cryptographic capabilities
   to support any form of privacy, authentication

NEW
but there are no built-in cryptographic capabilities
   to support any form of confidentiality, authentication

** Section 7.
   In order to fully protect TCP connections (including their control
   flags) IPsec or the TCP Authentication Option (TCP-AO) [36] are the
   only current effective methods. Other methods discussed in this
   section may protect the payload

The text should be more precise on what “protect” means.  IPSec and TCP-AO
provide different security services.  IPSec will provide confidentiality and
integrity, but TCP-AO only provides the latter.

Likewise, the reference to protect the payload needs to be clarified.  Which
exact security service does “protect” align with?

** Section 7.  Further discussion on TCP stack fingerprinting would be helpful.
 RFC8546 notes that “In particular, the metadata, such as sequences of
interpacket timing and packet sizes, can be used to    infer other parameters
of the behavior of the protocols in use or to fingerprint protocols and/or
specific implementations of those protocols.”  However, it’s more than that –
it’s the specific choices of options, their sequence in the packets, etc. 
Pretty much everything a tool like nmap does to profile host OSes.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 22 Sep 2021 22:18:45 -0700

Note below...
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Sep 22, 2021, at 8:59 PM, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 
> ...
> ———————————————————————————————————
> ..
> .
> ** Section 7.

It doesn’t have to; see  https://datatracker.ietf.org/doc/html/draft-touch-tcp-ao-encrypt <https://datatracker.ietf.org/doc/html/draft-touch-tcp-ao-encrypt>

Joe

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Sep 2021 12:56:46 +0100

> On 23 Sep 2021, at 04:59, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 

The header format description uses the approach described in draft-mcquistin-augmented-ascii-diagrams-08 to try to be both human and machine readable. 

It seems this particular syntax fails at the human readable part :-)

It’s also not clear it’s well specified in draft-mcquistin-augmented-ascii-diagrams.

Maybe Options.size() or size(Options) would be clearer?

Colin

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 23 Sep 2021 14:36:17 +0000

Hi Joe!

From: iesg <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, September 23, 2021 1:19 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; [email-masked] Extensions <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: [tcpm] Roman Danyliw's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

Note below...
—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>

On Sep 22, 2021, at 8:59 PM, Roman Danyliw via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

It doesn’t have to; see  https://datatracker.ietf.org/doc/html/draft-touch-tcp-ao-encrypt

[Roman] Interesting. Thanks for the pointer.

[Roman] I still recommend being clearer on what “protect” means by explicitly enumerating the security services provided.

Roman

Roman

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 30 Sep 2021 14:48:16 -0700

> It seems this particular syntax fails at the human readable part :-)

Yeah, if you want to ensure I understand this syntax you have to make
draft-mcquistin-augmented-ascii-diagrams a normative reference :)

> Maybe Options.size() or size(Options) would be clearer?

Mild preference for the former, here, but either seems a clear improvement
over Options#Size.

-Ben