Re: [tcpm] DISCUSS: draft-ietf-tcpm-tcpsecure

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Anantha Ramaiah (ananth) wrote:
>  
> Hi,
> 
> I am forwarding  [sorry about the long delay] these comments received
> during IESG review ( as suggested by Lars) to get some feedback from
> TCPM. The suggestion below from Cullen is to add more text to the
> middle-box section and also add some notes to the AS. [ Pl refer below]
> 
> My comments here are : [ you can find them inside the email responses
> below, but listed here in brief ]
> 
> - We have alreaady have mentioned the challenges that middle-boxes pose,
> this is not just limited to the current RFC, RFC  TCP-MD5 or TCP-AO has
> issues and list can go on. 

I think the difference is that people expect NATs and other devices that
modify TCP packets to affect any authentication mechanism (MD5, AO), but
that they wouldn't expect it to affect this mechanism.

I'm not sure how it would, though - what is the case they're thinking of
here that would cause this to fail with a middlebox? (transparent
rewriting maybe?)

> - Regarding the case of a server opening closing connections at a rapid
> rate implies "short-lived" connections. The document currently says that
> these mitigations can be very useful in case of long lived connections,
> short-lived connections may or may not want to implement this. So my
> thinking is that the current text gives more flexibility for
> implementers to chose what they want to do, they can have a socket
> option to turn these mitigations to select ports etc., In case of where
> the connections are made/broken at a rapid rate, there are other
> problems that come into play : for example the port collisions happening
> because the TCB in the server is stuck in the TIMEWAIT state and that
> causes denying the incoming connection. The orthogonal and somewhat
> important point is that to note is that typically cleanup involves a
> client sending an FIN and not RST, sending RST has many other issues and
> should be used with caution and that typically happens today in
> implementations. So, I am not really sure about adding a text that says
> "a server should not be doing that"

The point of the comment focuses on the increased load due to packet
exchange, not just the lack of benefit. For high-rate servers, there are
thus not only reasons they might not benefit, but reasons they might
want to deliberately avoid this mechanism. Yes, there are other
challenges to building a high-rate server, but it's worth noting that
this mechanism might complicate that situation more than it helps.

I think that's worth stating, though should take only a sentence or two.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAktLdioACgkQE5f5cImnZrs+fACgicnAFT5xYOujMnJVbwRmWv5K
u1UAn0wjGOSvA6IkiEoogJx/Nn0QHBFu
=7F/U
-----END PGP SIGNATURE-----