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

[Wesley Eddy <[e-mail]>]

Hello, at long last I've gone through these comments and have responses:


On 9/22/2021 11:59 PM, Roman Danyliw via Datatracker wrote:
> 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 tohttps://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?

I agree, this could be rephrased.  In the WG discussions, I think these 
are not known to be in current use, however, someone using them might 
not be participating in the WG (we are more concerned with typical 
Internet use, and not MLS systems).  The IETF has not got rid of these, 
though it could make sense to do so in the future.  Is there a specific 
way you'd like to see this described, or should I just take a stab at it?


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

Colin mentioned earlier that this is from 
draft-mcquistin-augmented-ascii-diagrams.  Based on your feedback, that 
'Options#Size' notation has been changed to a "size(Options)", and this 
is reflected in my working copy.


>
> ** 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].

ACK; Zahed also mentioned this and I think [41] is a good reference 
because it includes some more context beyond just [Morris1985] alone, 
and of course it includes reference to [Morris1985] itself as well.


>
> ** 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

ACK.  This is updated in my working copy.


> ** 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?

Based on your exchange with Joe, I changed "protect" to "provide 
confidentiality and integrity for" in both places.


> ** 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.

Good point.  In the working copy, I've added this below, though you 
might be able to suggest improvement:

  * There are also methods of "fingerprinting" that can be used to infer
    the host TCP implementation (operating system) version or platform
    information.  These collect observations of several aspects such as
    the options present in segments, the ordering of options, the
    specific behaviors in the case of various conditions, packet timing,
    packet sizing and other aspects of the protocol that are left to be
    determined by an implementer, and can use those observations to
    identify information about the host and implementation.