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

[Roman Danyliw via Datatracker <[e-mail]>]

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.