IETF conflict review for draft-touch-tcp-ao-nat
conflict-review-touch-tcp-ao-nat-00

No objection to the draft, but I am curious whether the clients will know they're behind a NAT or whether all clients will end up setting this all the time.

This is the lamest comment in the history of conflict reviews, but I found the title, "A TCP Authentication Option NAT Extension", confusing (we're extending TCP-AO, not NATs). The abstract is much clearer:

   This document describes an extension to the TCP Authentication
   Option (TCP-AO) to support its use over connections that pass
   through network address and/or port translators (NATs/NAPTs). 

Not a big deal, but perhaps this could be considered as the document moves through the process.

I wondered if it'd be worth adding some security
consideration text about possible attacks that might be
enabled by this if e.g. there's a load balancer on the NAT'd
end with different devices behind the NAT having the same
master key - presumably a bad actor might be able to
re-direct or replay some traffic even if there's a low
probability that that'd not be detected unless a large
amount of traffic is re-directed or replayed. Not sure if
the attack is practical though, I guess it'd need a sequence
number collision.

I checked with the IDR and SIDR WGs and no concerns were raised. I have hence cleared my Discuss.

There was one technical comment which I pass to the author for his consideration:

   >> TCP-AO-NAT SHOULD NOT be used with both flags set in IPv4,
   however, as the result would rely entirely on the ISNs alone.


  The preceding paragraph says that the ISNs alone provide most of the randomness ("KDF input randomness is thus expected to be dominated by that of the ISNs") so the justification for the sentence quoted above isn't obvious.
- RFC5389 is all very well, and broadly related to the topic. But the citation is provided without context, or more accurately, it's cited out-of-context. I was expecting to go look at RFC5389 to find out something useful about localNAT and remoteNAT, but no.