Subject: [Ietf-behave] About that TCP draft ....

From: Cullen Jennings <[email-masked]>
Date: Wed, 21 Sep 2005 14:31:23 -0700 (PDT)

We seem to have closed up the UDP stuff and I was hoping to solve some of
the issues around the TCP work. Trolling through old email traffic, I formed
a list of issues that have been discussed. We may have already come to
closure on many of these. I probably missed many. My take of the conclusions
may be all wrong, but ...

When there is not an open mapping, what is the response to an SYN? I think
we agreed not to send a RST. There has been discussion on sending an ICMP
error of some sort.

When there is an open mapping, what to do with incoming packets such at SYN,
SYNACK, and LAST_ACK? I suspect the only reasonable answer is forward them.

Should the NAT track TCP sequence numbers and timestamps and be able to
remap them when a stream is manipulated. I believe we came to the conclusion
that NATs should not be required to do this. Clearly a NAT running a
specific ALG on a protocol inside a TCP stream might have to do that but
that is about NATing some protocol that uses TCP non NATing a generic TCP
stream. 

There was discussion of if the NAT should initiate keep alives. I don't
think we got to consensus on this but it seemed at last IETF that most
people where not in favor of this.

There was discussion of timer values - one of the comments I got that made a
lot of sense was that we should logical derive these based on the
recommendations in the TCP RFCs.

Anyways, I am sure these are not all the issues and I may have summarized
them in completely the wrong way. I'm not trying to really get the list
right here - I just want to start discussion on what the issues are, what
the proposed solutions to the issues are, and pro's and cons. If we can get
out of the next IETF meeting and be very close to done on a WG TCP document
I would be very happy.

Cullen <with my chair hat on>

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 24 Sep 2005 09:34:22 -0700 (PDT)

> we agreed not to send a RST. There has been discussion on sending an ICMP

[suresh] My recollection is to simply drop. 

> SYNACK, and LAST_ACK? I suspect the only reasonable answer is forward them.

[suresh] Cullen - By "open mapping", if you are refering to an open TCP NAT
Session, I agree with what you say. However, if "open mapping" refers to an
open Binding, permitting or not permitting the SYN packet depends on the
directionality of the Binding on the NAT.

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Sat, 15 Oct 2005 23:48:26 -0700 (PDT)

Hello all,

A new version of draft-hoffman-behave-tcp-03 is now up that addresses
these issues.

The major changes are:
1. Expansion of Security Considerations
2. Modifications of some requirements to reflect group consensus.

> we agreed not to send a RST. There has been discussion on sending an ICMP

Correct. Not sending an RST is crucial for all TCP traversal approaches.
NATs can silently drop packets; this can raise a security concern (see
draft). This draft allows NATs to return ICMP errors to alleviate this
problem, but doesn't require/recommend/not-recommend it. 

> SYNACK, and LAST_ACK? I suspect the only reasonable answer is forward them.

Agreed. Specifically, this draft requires all valid TCP transitions
should be supported; it allows NAT vendors to forward all packets if
they chose, or implement more stringent TCP checks (checking in-window
packets etc).

> that NATs should not be required to do this. 

Agreed. This draft does not _require_ them to track sequence numbers;
security conscious NATs will want to track them, however, and this draft
covers this aspect under security considerations.

> people where not in favor of this.

This draft does not require keepalives; it leaves them up to the vendor.

> recommendations in the TCP RFCs.

Yes. RFC 1122 mentions several timers for TCP stacks (keepalive,
in-flight packets etc). This draft incorporates them.

I'd appreciate comments, feedback etc on the draft. 

Thanks,
-- 
Saikat
Attachment:
signature.asc