Re: [9fans] IL and NAT

Re: [9fans] IL and NAT

[geoff]

NAT routers generally have to rewrite port numbers (not just IP
addresses) for protocols that use them, and ports numbers are at
different offsets and of potentially different sizes in different
protocol's headers.  IL's port numbers appear later than TCP's and
UDP's, for example.  NAT routers will generally understand the headers
of TCP, UDP and ICMP at minimum, but I haven't encountered one yet
that understood IL (even Lucent's own).

Contrary to what Scott just said, it's not each application that has
to be added to a NAT router, but each protocol that rides directly on
IP (or beside it).

Re: [9fans] IL and NAT

[Christopher Nielsen]

On Fri, 17 Nov 2000 geoff@x.bell-labs.com wrote:

> NAT routers generally have to rewrite port numbers (not
> just IP addresses) for protocols that use them, and
> ports numbers are at different offsets and of
> potentially different sizes in different protocol's
> headers.  IL's port numbers appear later than TCP's and
> UDP's, for example.  NAT routers will generally
> understand the headers of TCP, UDP and ICMP at minimum,
> but I haven't encountered one yet that understood IL
> (even Lucent's own).

That makes perfect sense, and if I would have been a little
more patient and thought it through, I probably would have
figured that out.

That said, I have some sway with Cisco's development team,
so I _might_ be able to get them to implement support for
IL. I'll let you know how it goes.

-- 
Christopher Nielsen
cnielsen@pobox.com

Re: [9fans] IL and NAT

[Boyd Roberts]

From: <geoff@x.bell-labs.com>

> NAT routers generally have to rewrite port numbers (not just IP
> addresses) ...

yes, i tracked down a particularly nasty case of a firewall
doing NAT to UDP packets with a destination port of 53 [DNS].
i found that some DNS servers would not reply to requests
that didn't have a source port of 53; NAT having munged
the source address and port.

i would have found it a lot faster if my pleas for a
protocol analyser had been heeded -- i'd only been
bitching about it for a _year_.  somehow i managed
to forge up some queries that demonstrated the
problem.

i also had the added stumbling block of not knowing or
being able to know the firewall's config.  contractors
were prohibited from going near them, except when things
were _really_ screwed up.

``oh, but that's impossible, boyd... err, i see''.

Re: [9fans] IL and NAT

[Scott Schwartz]

| Contrary to what Scott just said, it's not each application that has
| to be added to a NAT router, but each protocol that rides directly on
| IP (or beside it).

Isn't it the case that some applications, like ftp, encode ip address
and port information in application layer traffic, which NAT has to
account for?  Linux seems to have code to handle that sort of stuff
(linux/net/ipv4/ip_masq*).

Re: [9fans] IL and NAT

[Boyd Roberts]

From: <nigel@9fs.org>

> In fact, since it has been mentioned, Lucent devices (neé Ascend),

you mean: née; the feminine past participle of the verb 'naître' [to be born].
the past participle is 'né' and is conjugated with 'être' [to be].  it's highly
irreguler, as most verbs, in the past tense, are conjugated with 'avoir' [to
have].

    je suis né [i was born]
    je suis née [if i was female]

bit like 'mourir' [to die]:

    je suis mort
    je suis morte

where normally you'd use 'avoir', except for movement and reflexive verbs:

    j'ai deconné [i screwed up or pissed about]

and no 'e' on the end of the past participle if you conjugate with 'avoir'.

but i digress :-)  je déconne...

Re: [9fans] IL and NAT

[Theo Honohan]

nigel@9fs.org wrote:
> 
> Before we are too down on NAT implementations, there is a distinction
> between NAT and NAPT, according to various RFCs and associated
> documents.

Yes, quite.  I didn't mean to be "down on" simple NAT implementations;
OTOH, I do still think it's a fair to say that you need to do both NAT
and NAPT to be a viable product, these days.

Re: [9fans] IL and NAT

[nigel]

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

Before we are too down on NAT implementations, there is a distinction
between NAT and NAPT, according to various RFCs and associated
documents.

NAT means what is says: address translation.  NAPT means address and
port.  You can simply translate addresses and maintain the port, but
this means that typically only one internal node can communicate.If
you do this, then the protocol is irrelevant, and IL would pass
through.

In fact, since it has been mentioned, Lucent devices (neé Ascend),
worked this way until it became apparent that Cisco had implemented
NAPT and they rolled out the full monty. They called it "single address
translation".

Once you choose to translate ports as well, as has been said, you need
to understand where the ports are; for TCP and UDP it is in the same place,
so they get done. It is completely unsurprising that other protocols aren't.

ICMP gets done because it's dull if you can't traceroute and ping. It takes
hacks, but it can be done.

FTP is depressing. Anyone out there designing protocols: take note, don't
embed IP addresses in the stream.

Others are as bad, or insoluble: luckily, they are less important, like IRC
or RealAudio.

On top of this, to create some 'reliability', commerical NAT routers
have a list of TCP and UDP ports which they are prepared to translate.
'Known good' if you like.  My Pipeline 75 does not do POP3
automatically.  I had to tell it to, despite the protestations of the
manuals.  I looked for a software update, but since Lucent bought
them, this doesn't happen any more.  Some other products, I
understand, refuse straightforward protocols like POP3 despite best
efforts.

So, the summary is use 9p over TCP, not IL, unless you can rewrite
your router. This is becoming easier since both FreeBSD and Linux
have WAN drivers, and NAT code.

As it happens, all translation in FreeBSD is done using a library,
with plug-ins for various awkward protocols.  Fix the library, and all
the various translators (natd, pppd, pppoed) would all fall into
line. Modifying the implementation to do IL would be straightforward
I think.


[-- Attachment #2: Type: message/rfc822, Size: 2026 bytes --]

From: Theo Honohan <theoh@chiark.greenend.org.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] IL and NAT
Date: Sat, 18 Nov 2000 13:53:50 +0000
Message-ID: <E13x8RD-0007iy-00@chiark.greenend.org.uk>

geoff@x.bell-labs.com wrote:
> scott wrote:
> >
> > Isn't it the case that some applications, like ftp, encode ip address 
> > and port information in application layer traffic, which NAT has to 
> > account for?  Linux seems to have code to handle that sort of stuff 
> > (linux/net/ipv4/ip_masq*). 
>
> I'm not sure; it's certainly possible that individual applications do
> such things.

I think Scott's right.  All viable NAT products do this, although it's not
strictly part of NAT.  A search for "NAT" on Cisco's site confirms
that they support the use of "PORT" in ftp, and a slew of features of
other protocols that would otherwise be broken by NAT.

Re: [9fans] IL and NAT

[Steve Kilbane]

> My gut response is bollocks, but is there any reason that IL
> wouldn't work through NAT other than Cisco hasn't written
> the code to handle it? 

If I recall Firewall-1 correctly, you can bodge up support for
rare protocols by specifying some low-level transformation rules:
if (value at offset x) == y, change bytes elsewhere accordingly.
I was only skimming docs at the time, and never got around to
reading it in detail, so I might be completely wrong. Point is,
though, does your Cisco support something similar?

As for it going into the Cisco base product (from which an entire
range of Cisco units are produced), I'd put the chances at approximately
equal to the market: practically none. Even if you gave them the code
for free, they'd have to make sure it didn't break anything else, and
that'd cost them.

steve

Re: [9fans] IL and NAT

[presotto]

[-- Attachment #1: Type: text/plain, Size: 154 bytes --]

we don't do any in home stuff, that all goes off with avaya and Microelectronics,
our 2 current spin offs.  Orinoco (aka wavelan) also goes with micro.

[-- Attachment #2: Type: message/rfc822, Size: 1510 bytes --]

From: anothy@cosym.net
To: 9fans@cse.psu.edu, cnielsen@pobox.com
Subject: Re: [9fans] IL and NAT
Date: Sat, 18 Nov 2000 01:32:53 -0500
Message-ID: <20001118063257.01E01199F7@mail.cse.psu.edu>

//That said, I have some sway with Cisco's
//development team, so I _might_ be able to
//get them to implement support for IL.

ooh, that'd be embarasing. Cisco supporting a
protocol developed at Bell Labs that Lucent's
own products don't support. er, or does Lucent
not do that sort of thing any more? maybe we
should go talk to Avaya...
-α.

Re: [9fans] IL and NAT

[Theo Honohan]

geoff@x.bell-labs.com wrote:
> scott wrote:
> >
> > Isn't it the case that some applications, like ftp, encode ip address 
> > and port information in application layer traffic, which NAT has to 
> > account for?  Linux seems to have code to handle that sort of stuff 
> > (linux/net/ipv4/ip_masq*). 
>
> I'm not sure; it's certainly possible that individual applications do
> such things.

I think Scott's right.  All viable NAT products do this, although it's not
strictly part of NAT.  A search for "NAT" on Cisco's site confirms
that they support the use of "PORT" in ftp, and a slew of features of
other protocols that would otherwise be broken by NAT.

Re: [9fans] IL and NAT

[anothy]

//That said, I have some sway with Cisco's
//development team, so I _might_ be able to
//get them to implement support for IL.

ooh, that'd be embarasing. Cisco supporting a
protocol developed at Bell Labs that Lucent's
own products don't support. er, or does Lucent
not do that sort of thing any more? maybe we
should go talk to Avaya...
-α.

Re: [9fans] IL and NAT

[geoff]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

I'm not sure; it's certainly possible that individual applications do
such things.

The usual problem with ftp is that by default ftp clients, especially
older ones, tend to trigger connections back from the target system to
port 20.  ftp's so-called ``passive'' mode forces the connections to
be placed from the initiating system and avoids this problem.


[-- Attachment #2: Type: message/rfc822, Size: 1786 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] IL and NAT
Date: Fri, 17 Nov 2000 22:02:08 -0500
Message-ID: <20001118030208.7775.qmail@g.bio.cse.psu.edu>

| Contrary to what Scott just said, it's not each application that has
| to be added to a NAT router, but each protocol that rides directly on
| IP (or beside it).

Isn't it the case that some applications, like ftp, encode ip address
and port information in application layer traffic, which NAT has to
account for?  Linux seems to have code to handle that sort of stuff
(linux/net/ipv4/ip_masq*).

Re: [9fans] IL and NAT

[Scott Schwartz]

| My gut response is bollocks, but is there any reason that IL
| wouldn't work through NAT other than Cisco hasn't written
| the code to handle it? 

That's exactly the problem with NAT.  Every application has to be
specially hacked into the firewall.

To my way of thinking, it's much nicer to import /net from the firewall
instead.

[9fans] IL and NAT

[Christopher Nielsen]

I've been tinkering with connecting to my fileserver over IL
at home via my DSL line across the Internet and through a
Cisco router acting as a firewall and NAT.

The router keeps responding with ICMP host unreachable, but
I know I can get to the machines in question.

I've opened a TAC case with Cisco to see what they had to
say. Having probably never even heard of IL, the engineer
has responded that he doesn't think IL is "NAT compliant".

My gut response is bollocks, but is there any reason that IL
wouldn't work through NAT other than Cisco hasn't written
the code to handle it? 

-- 
Christopher Nielsen
cnielsen@pobox.com