Subject: Re: [Ietf-behave] Next rev on TCP Behavior

From: Senthil Sivakumar <[email-masked]>
Date: Tue, 12 Apr 2005 14:29:19 -0700 (PDT)

I believe there was a test conducted on the behavior of many NAT boxes, 
does any
one have the data of what the timeouts of different boxes were?

Also, does anyone know if TCP keepalives are implemented by
the vendors and if so what percent of these boxes implement them?
thanks
Senthil
At 08:14 AM 4/10/2005 -0700, Pyda Srisuresh wrote:
Folks,

The revised behave-tcp draft (i.e., sivakumar-behave-nat-tcp-req draft cited
below) is completely reworked in that issues that are not tcp-specific (IP
fragmentation, port reservation, Path MTU handling, ICMP error handling etc)
are moved to the behave-gen draft. The next rev of ford-behave-gen draft will
include these. Below are additional highlights of the behave-tcp draft.
1. A consolidated requirements summary section lists a total of 6 
requirements.
2. A new "Hints to implementors" section is added. Text relating to supporting
embedded ALGs is moved to be under this section.

Do send in your comments and thoughts on the draft, so we can have a
discussion. Thanks. Let me start off by soliciting comments on the following
specific items.
1. Timeout recommendations:
Recommended value for SYN timeout: 30 secs
Recommended value for TCP session timeout: 30 mins.
Recommended value for close timeout:  2 x MSL or 4 mins.
Do we have work group consensus on these values?

2. NAT initiated TCP-keppalives: We made this requirement to be a MAY. We did
this because the session timeout recommendation is reasonably large (i.e., 30
mins above) and we donot need to mandate NAT devices to send in keep-alives.
Any comments?

3. NAT initiated RST: We made this as a SHOULD requirement. We did this 
because
NAT retains state of an end-to-end TCP session. Upon session timeout, simply
loosing the session state without notifying the end nodes would leave the
endnodes in zombie state. Considering the large session timeout, we left this
as a SHOULD.

Any comments?

Thanks.

cheers,
suresh
--- Senthil Sivakumar <ssenthil@xxxxxxxxx> wrote:
> The next revision of TCP Behavior draft is available at:
>
> 
http://www.ietf.org/internet-drafts/draft-sivakumar-behave-nat-tcp-req-01.txt
>
> This revision captures the WG discussions on this topic.
>
> Please review this and let us know your comments.
>
> Senthil
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Saikat Guha <[email-masked]>
Date: Tue, 12 Apr 2005 15:32:01 -0700 (PDT)

> one have the data of what the timeouts of different boxes were?

The STUNT tests include TCP timeout tests. The results are online at
https://www.guha.cc/saikat/stunt-results.php

-- 
Saikat
Attachment:
signature.asc

---

From: Senthil Sivakumar <[email-masked]>
Date: Thu, 21 Apr 2005 14:32:08 -0700 (PDT)

At 06:45 PM 4/20/2005 -0700, Pyda Srisuresh wrote:

--- Senthil Sivakumar <ssenthil@xxxxxxxxx> wrote:
>
> >
> >
> >That brings up another question, if a SYN (or any packet) is filtered,
> >what should the response be?
[suresh] I believe, NAT should simply drop the TCP packets that are not
permitted. Silent discard of unpermitted/erroneous datagrams will prevent
"broadcast storms" and unneeded clutter in the network.
I believe, it is a BAD idea to generate RST pakets because that gives the
attacker clues when the attacker does port scan on the NAT device. 
Further, the
attacker could keep the NAT device busy generating RSTs.
I agree that NAT responding with a RST is not a good idea. However, there are
cases where the TCP stack in the NAT box will generate RSTs for stray TCP
packets. For example in case of a SYN received on an outside interface (coming
from out->in) for which a NAT translation does not exist. NAT cannot drop 
this packet
because it is addressed to the interface's address so it simply passes the 
packet
up in the stack. The TCP stack would receive the SYN and probably respond with
a RST since there isn't any application listening on the port.

Senthil

> >                             Silently dropping the packet opens the NAT
> >up to IP Spoofing attacks where an adversary in the middle of the
> >network spoofs the NATs IP in a SYN, and replies with a spoofed ACK
> >knowing that the SYNACK was dropped silently by the NAT; thus fooling
> >the victim.
[suresh] Sorry, I donot understand what the problem is.

> >           Generating RST packets seems to violate the semantics of
> >RST, which in my opinion means the host replying can authoritatively say
> >that there is no application expecting to receive the packet.
> >
[suresh] Right. As I said before, I agree, it is not a good idea to send RST.

> >I propose the NAT should respond with ICMP Destination Unreachable
> >(Code: Host unreachable or Port unreachable) much like a router responds
> >with net unreachables. The response would naturally be subject to ICMP
> >rate limiting to prevent reflection attacks. Second, NATs should process
> >incoming ICMP Host or Port Unreachables the same way they would process
> >a RST or FIN/FINACK. Thoughts?
>
> Does either of these messages cause the originating host to behave
> differently?
> I think sending a RST or ICMP Unreachable would not prevent a host app 
from
> retrying
> a number of times (it is programmed to retry), right? Of course, I agree
> that ICMP
> unreachables are slightly better for the rate limiting reason.
>

[suresh] I believe, the NAT device may optionally send ICMP Destination
unreachable message for the cases where a certain session tuple is not
permitted. However, for diagnostic purposes, the NAT device SHOULD perhaps be
required to log the error and record the event in a statistic counter.
As fo rthe ICMP code, I would recommend using code 10 (Communicaion with
destination host administratively prohibited). It woudl have been nice if we
had another code that would indicate "Communication with destination host port
administratively prohibited". But, we dont. So, I suggest, we use the same 
code
for host as well as port filtering.

The above logic is not specific to TCP alone and is appliable to UDP. So, we
shoudl capture this in the behave-gen draft.
As you might recall, we talked about capturing ICMP message generation as well
as processng concerning PMTU (i.e., for the cases where framentation is needed
with DF set) in the behave-gen draft in the Minneapolis meeting. We could
extend the coverage to include this as well.
> >Cheers
cheers,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 24 Apr 2005 09:55:45 -0700 (PDT)

Senthil,

Please see my comment inline below.

cheers,
suresh

> a RST since there isn't any application listening on the port.
[suresh] I understand and agree with what you say about ports for which the NAT
device is acting as endpoint and no NAT involved. I was refering only to the
ports  for which the NAT functon is applicable - say, the block of ports that
may have been reserved for NAT use (or) the ports that currently have a port
binding for outgoign sessions, but inbound session is not permitted.   

cheers,
suresh

---

From: Kaushik Biswas <[email-masked]>
Date: Sun, 24 Apr 2005 12:13:13 -0700 (PDT)

Hi Suresh,

Please see inline for my comments....

At 09:55 AM 4/24/2005 -0700, Pyda Srisuresh wrote:
Senthil,

cheers,
suresh
> a RST since there isn't any application listening on the port.
[suresh] I understand and agree with what you say about ports for which 
the NAT
device is acting as endpoint and no NAT involved. I was refering only to the
ports  for which the NAT functon is applicable - say, the block of ports that
may have been reserved for NAT use (or) the ports that currently have a port
binding for outgoign sessions, but inbound session is not permitted.
[Kaushik] If we are not going to generate RST for such out->in packets 
destined to the block of ports that may have been reserved by NAT, then 
there would be an inconsistency in behavior. Since if this port were to be 
a port which NAT had *not* reserved then it would be going to the local TCP 
stack of the router and it would anyway generate a RST as there is no 
associated TCP control-block for this flow. Actually by not sending a RST 
for this such out->in packets one would be giving the attacker more clue as 
to which ports are reserved by NAT and which are not.

Thanks,
Kaushik

cheers,
suresh