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

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-touch-tcp-ao-nat@tools.ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-touch-tcp-ao-nat-04

The IESG has completed a review of draft-touch-tcp-ao-nat-04 consistent
with RFC5742.


The IESG has no problem with the publication of 'A TCP Authentication
Option NAT Extension'  as an Experimental
RFC.


The IESG has concluded that this work is related to IETF work done in WG
TCPM, but this relationship does not prevent publishing.


The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-touch-tcp-ao-nat/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-touch-tcp-ao-nat/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
I am sorry for the late Discuss.

I would like to check with the SIDR and IDR WGs to see if this has any implications for their protocols.

[Ballot comment]

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.

[Ballot comment]
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.

The draft draft-touch-tcp-ao-nat-04
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

It's abstract says:
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). This
extension changes the data used to compute traffic keys, but does
not alter TCP-AO's packet processing or key generation algorithms.

It was reviewed by Brian Carpenter, its author (Joe Touch) published
this -04 version, which has addressed the issuies Brian raised.

Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org