Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt

["[e-mail]" <[e-mail]>]

Med,

...
> If that is what you want, encrypt. 
> [Med] You can  … but for off-path attacks, this can be fixed without encryption. That’s the same reason we have the following for ISNs, for example, in draft-ietf-tcpm-rfc793bis:
>  
>            The Initial Sequence Number.  The first sequence number used
>            on a connection, (either ISS or IRS).  Selected in a way that
>            is unique within a given period of time and is unpredictable
>            to attackers.

I raised concerns with that text before. It exceeds the advise on which it is derived, notably RFC 6528 - which only provides an algorithm example, i.e., IF you are going to use such an algorithm, here’s one to use. It claims to update RFC793 but only in providing an *example* algorithm. Note the number of caveats about all aspects of this algorithm in the preceding text. 

> That’s consistent with the reco in rfc3552#section-3.5
>  
>    However, designers are expected to give more weight to
>    attacks which can be mounted by off-path attackers as well as on-path
>    ones.

That RFC describes how to write security considerations sections, not specifically advise to designers (which is why this is just discussion text rather than stated as a normative recommendation).

> and also documents such as draft-irtf-pearg-numeric-ids-generation.  

That is an IRTF doc, not IETF.

Although I agree that this issue has been represented in other documents, it has consistently been noted as per RFC 6528:

   Good sequence numbers are not a replacement for cryptographic
   authentication, such as that provided by IPsec [RFC4301 <https://datatracker.ietf.org/doc/html/rfc4301>] or the TCP
   Authentication Option (TCP-AO) [RFC5925 <https://datatracker.ietf.org/doc/html/rfc5925>].