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

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 10 Jan 2010 23:02:38 -0800

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. So what we currently have is enough, IMO. But
I am also ok to write more text as suggested by Cullen. If there is a
consensus from the list I can go update the document. If that is the
case I would like to qualify the NATs/Firewalls as "the NAT/Firewalls
which doesn't account the tcp-secure changes" [FWIW, the Cisco
Firewalls, esp IOS based ones have these fixes in place for a long time]

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

Comments welcome.

-Anantha

> -----Original Message-----
> From: Cullen Jennings (fluffy) 
> Sent: Thursday, October 08, 2009 9:25 AM
> To: Cullen Jennings (fluffy); Anantha Ramaiah (ananth); Lars Eggert
> Cc: [email-masked]; 
> [email-masked]
> Subject: Re: DISCUSS: draft-ietf-tcpm-tcpsecure 
> 
> 
> We talked about this issues on the IESG call and I'd like to 
> propose the following plan
> 
> 1) Update the middle-box section to explain there are some 
> cases with some existing firewalls/nats that causes the ACK 
> approach to not work.  
> Could even encourage
> 
> 2) in the applicability section, add a bit that says about 
> when a server should not do this. I would something along 
> lines of some server that are not severely impacted by an 
> attacker closing a connection, and where the number of 
> connections requires rapid clean up of state. So certainly a 
> BGP should do this but a server such as some web servers 
> where state of TCP connections is an issue and an attacker 
> killing a connecting is not a big deal as it will just be 
> redone and it often hard to guess the source port.
> 
> Would a plan along these lines be acceptable for folks?
> 
> 
> On Oct 7, 2009, at 9:05 PM, Cullen Jennings wrote:
> 
> >
> > Thank you both for info. Do you know what the small residential NATs
> > (linksys/netgear/dlink) stuff do? I know I could go test - I have a 
> > few boxes full of them here but uh, too much email to read 
> to get to 
> > work doing testing :-)
> >
> > Updating the middle-box section to talk about this might be a good 
> > idea but don't worry about doing anything yet - I'm still 
> getting up 
> > to speed on what the issues are here and once I understand 
> it I hope 
> > it is all just a non issue.
> >
> >
> > On Oct 7, 2009, at 7:57 PM, Anantha Ramaiah (ananth) wrote:
> >
> >> Cullen,
> >>  Adding to what Randy said in the other email : (pl see inline
> >> comments)
> >>
> >>> -----Original Message-----
> >>> From: Cullen Jennings (fluffy)
> >>> Sent: Wednesday, October 07, 2009 5:37 PM
> >>> To: [email-masked]
> >>> Cc: [email-masked];
> >>> [email-masked]
> >>> Subject: DISCUSS: draft-ietf-tcpm-tcpsecure
> >>>
> >>> Discuss:
> >>>
> >>> I have a question about the applicability of this that 
> I'd like to 
> >>> understand the answer to before trying to answer the "updates" 
> >>> question Lars raised. Imagine we have a client C, talking 
> from the 
> >>> "inside" of a firewall that tracks TCP state, to a server 
> S on the 
> >>> "outside" of the firewall. If C sends a RST, the firewall 
> forwards 
> >>> it and clears state, but when the RST arrives at S. The 
> reset seq # 
> >>> is within the window but not exact. S sends and ACK, but 
> (this is my 
> >>> question), will the firewall forward the ACK to C or just 
> silently 
> >>> drop it?
> >>
> >> Good question, atleast IOS firewalls have fixed this in their code 
> >> for what I can recall ( I can double check if interested 
> since it has 
> >> been a long time when that event happened!). If this RFC becomes a 
> >> standard other firewall vendors would also implement this fix I 
> >> suppose.
> >> The inter-op what we did included teams within Cisco and outside 
> >> (Juniper, QNX etc., ), the focus was on fixing the host behaviour, 
> >> not the middle-boxes..
> >>
> >> So, biting a bit here : if this is a general problem then 
> every TCP 
> >> RFC should have a column saying "middlebox compliance" ;-) 
> Actually 
> >> we do have a section 9 in the draft that talks about "middlebox 
> >> considerations" Do you think some more text that needs to be added 
> >> there?
> >>
> >> Firewalls could also do the proxy i.e, send an RST for the 
> incoming 
> >> ACK if no flow exists releiving the end host to do this function, 
> >> FWIW.
> >>
> >>>
> >>> I know some firewalls might have the timers to forward 
> traffic for 
> >>> some time after the RST but do they all and is it long enough? Is 
> >>> there something I am just not understanding
> >>
> >> The characteristics of the timer value to use is somewhat 
> similar to 
> >> the TIME-WAIT value which is used on an active closer.
> >>
> >>> here that would cause this to work? I'm worried that servers with 
> >>> lots of clients connecting to them not being able to recover TCP 
> >>> connection in a timely matter might cause more harm that attacks 
> >>> that tear down TCP connections.
> >>
> >> Middleboxes definetely pose challenges and that is 
> probably true for 
> >> not just this RFC but other existing TCP RFC's as well.
> >>
> >> -Anantha
> >>>
> >>> This is a Discuss because I want to talk to the IESG & 
> authors about 
> >>> it before deciding an opinion on this draft.
> >>>
> >>> Thanks, Cullen
> >>>
> >>>
> >>>
> >
> 
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Jan 2010 11:04:10 -0800

Anantha Ramaiah (ananth) wrote:
> 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?)

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