draft-ietf-behave-rfc3489bis-04 - mistake

Dear Jonathan,
I found one more little mistake in draft 04:
chapter 11.11. on page 34, last sentence in paragraph. The key word 
USERNAME should be replaced by word SERVER.

Kind regards,
   Vladimir Marek

IP options and NATs

While reviewing draft-pashalidis-nsis-gist-legacynats-00.txt, I noticed:

    >     The discussion in this document is based on the
    >     following assumptions.  
    >     ...
    >     6.  The legacy NAT does not drop IP packets with a
    >         Router Alert Option (RAO) or an IPv6 extensions
    >         header.  Furthermore, the RAO or extension header
    >         is also present in the forwarded packet.  If the
    >         NAT does not do this, then there is no way for a
    >         GIST QUERY to traverse the NAT, which is a
    >         prerequisite for the mechanisms described in this
    >         document.

I am wondering how today's NATs handle IP options.  I asked our engineering
teams and found that Cisco's IOS NAT preserves IP options across the NAT,
but our PIX and our ASA drop all IP options.  Testing will be necessary to
determine how various residential style NATs (Linksys, etc.) handle IP
options such as RAO.

Does anyone know what other NATs do with RAO?

-d

RE: IP options and NATs

I certainly know of quite a number of residential NATs that discard IP
options.

On the slightly related subject of things being discarded I also know of
several that discard DSCP information too.

Regards,
Dave

* -----Original Message-----
* From: ietf-behave-bounces <at> list.sipfoundry.org 
* [mailto:ietf-behave-bounces <at> list.sipfoundry.org] On Behalf Of Dan Wing
* Sent: 02 August 2006 17:20
* To: ietf-behave <at> list.sipfoundry.org
* Cc: 'Pashalidis, Andreas'
* Subject: [Ietf-behave] IP options and NATs
* 
* While reviewing draft-pashalidis-nsis-gist-legacynats-00.txt, 
* I noticed:
* 
*     >     The discussion in this document is based on the
*     >     following assumptions.  
*     >     ...
*     >     6.  The legacy NAT does not drop IP packets with a
*     >         Router Alert Option (RAO) or an IPv6 extensions
*     >         header.  Furthermore, the RAO or extension header
*     >         is also present in the forwarded packet.  If the
*     >         NAT does not do this, then there is no way for a
*     >         GIST QUERY to traverse the NAT, which is a
*     >         prerequisite for the mechanisms described in this

Re: IP options and NATs

On Aug 2, 2006, at 18:19, Dan Wing wrote:
> I am wondering how today's NATs handle IP options.

Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of  
Transport Protocols in the Internet. ACM Computer Communication  
Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-evo- 
ccr05.ps

It's not about NATs in particular, but just probes a large number of  
Internet paths, and sure enough, *something* out there drops IP options.

Lars
--

-- 
Lars Eggert                                     NEC Network Laboratories

On Aug 2, 2006, at 18:19, Dan Wing wrote:
> I am wondering how today's NATs handle IP options.

Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of  
Transport Protocols in the Internet. ACM Computer Communication  
Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-evo- 
ccr05.ps

It's not about NATs in particular, but just probes a large number of  
Internet paths, and sure enough, *something* out there drops IP options.

Lars

Re: IP options and NATs

On Aug 2, 2006, at 20:23, Lars Eggert wrote:
> On Aug 2, 2006, at 18:19, Dan Wing wrote:
>> I am wondering how today's NATs handle IP options.
>
> Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution  
> of Transport Protocols in the Internet. ACM Computer Communication  
> Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp- 
> evo-ccr05.ps
>
> It's not about NATs in particular, but just probes a large number  
> of Internet paths, and sure enough, *something* out there drops IP  
> options.

Related question: anyone know of an empirical study that investigates  
how middleboxes deal with IP fragments and fragmentation?

Lars
--

-- 
Lars Eggert                                     NEC Network Laboratories

On Aug 2, 2006, at 20:23, Lars Eggert wrote:
> On Aug 2, 2006, at 18:19, Dan Wing wrote:
>> I am wondering how today's NATs handle IP options.
>
> Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution  
> of Transport Protocols in the Internet. ACM Computer Communication  
> Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp- 

Re: IP options and NATs

Le Thursday 03 August 2006 14:20, ext Lars Eggert a écrit :
> Related question: anyone know of an empirical study that investigates
> how middleboxes deal with IP fragments and fragmentation?

No. However:

Stateless firewall and "policy boxes" will typically either accept non-first 
fragments and check the first fragment for the usual stuff (port number, and 
minimum size...) - that's good; or they will drop fragmented packets - that's 
pretty bad.
Given the numerous software vulnerabilities that have been published wrt IP 
fragmentation in the recent (at least 2004), and mostly not-so-recent years, 
I'm also pretty confident that many admins have sort of blacklisted 
fragmented packets within their firewall rulesets.

As for NAT and statefull firewalls: at least Linux/Netfilter actually 
defragments packets first. I don't know for the others. That probably does 
not scale to heavily fragmented IP packets traffic anyway.

--

-- 
Rémi Denis-Courmont <Remi.Denis-Courmont <at> nokia.com>
Assistant Research Engineer

Re: IP options and NATs

> -----Original Message-----
> From: ietf-behave-bounces <at> list.sipfoundry.org 
> [mailto:ietf-behave-bounces <at> list.sipfoundry.org] On Behalf Of 
> Lars Eggert
> Sent: Thursday, August 03, 2006 7:20 AM
> Cc: Andreas Pashalidis; Behave; Dan Wing (dwing); Mark Allman
> Subject: Re: [Ietf-behave] IP options and NATs
> 
> On Aug 2, 2006, at 20:23, Lars Eggert wrote:
> > On Aug 2, 2006, at 18:19, Dan Wing wrote:
> >> I am wondering how today's NATs handle IP options.
> >
> > Alberto Medina, Mark Allman, Sally Floyd. Measuring the 
> Evolution of 
> > Transport Protocols in the Internet. ACM Computer Communication 
> > Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-
> > evo-ccr05.ps
> >
> > It's not about NATs in particular, but just probes a large 
> number of 
> > Internet paths, and sure enough, *something* out there drops IP 
> > options.
> 
> Related question: anyone know of an empirical study that 
> investigates how middleboxes deal with IP fragments and fragmentation?

Personally I am not aware of any study in this area. But based on my
personal experience I have seen issues when the non-first fragment
arrives on the NAT box before the 1st fragment (out-of-order fragments).

Re: IP options and NATs

> Related question: anyone know of an empirical study that
> investigates how middleboxes deal with IP fragments and fragmentation?

Again, anecdotal, but during the Behave session in Montreal on Diagnostics, 
someone noted that hairpinning is a problem for some NATs processing IP 
fragments.

Thanks,

Spencer 

(no subject)

Folks:

I just thought I should let everyone know that there was a brief  
presentation
of some of the key points in the behave-tcp draft at the TCPM session in
Montreal on Thursday afternoon. Originally, Saikat was supposed to  
give this
presentation, but he was unable to make it, so I ended up doing it.

The presentation covered the following points from the draft:
1) The handling of unsolicited SYNs;
2) The timeout of a connection after 2 hours and 4 minutes;
3) Leaving the exact behavior of the Time-Wait state unspecified.

On the first point, the presentation mentioned the various alternatives
considered and the decision by BEHAVE to have the NAT send an
ICMP Port Unreachable message after a 6 second delay. There was a good
discussion on the various alternatives, in particular the idea of  
using a soft ICMP error
code rather than "Port Unreachable". (Unlike the BEHAVE meeting,
no one questioned the choice of 6 seconds). In the end the TCPM
group said they were happy with the BEHAVE decision.
The one other comment received was a request to make the behavior
configurable, so that administrators could
configure the NAT box to silently drop the SYN instead.

There were no comments on points (2) and (3).

Those interested can see the slides used in the presentation on the  
IETF website,

Re: Dedicated draft for RTP keepalive?

In order to fix ideas, I have posted the following draft:
http://www.ietf.org/internet-drafts/draft-marjou-behave-app-rtp-keepalive-
00.txt

Xavier

-----Original Message-----
Object: Dedicated draft for RTP keepalive?

Looking at current applications, there are 2 fundamental behaviors that 
help RTP applications with regards to NAT traversal: "Symmetric RTP" and 
"Binding keepalives".

The first topic is shortly described in a short doc (draft-wing-behave- 
symmetric-rtprtcp-01).

The second topic is currently described in draft-ietf-mmusic-ice-09 
(section 7.12), which nicely describes two "binding keepalives" mechanisms: 
one for communications between ICE agents (STUN-keepalive case) and another 
for communications between non-ICE agents (RTP-keepalive fallback case). 
For the latter, I propose to extract it in a separate doc so that non-ICE 
applications can refer to a very short doc for basic "binding keepalives". 

What do you think?

Xavier