Re: NAT box spec? (RE: myth of the great transition)

2003-06-19 Thread james woodyatt 
On Wednesday, Jun 18, 2003, at 12:51 US/Pacific, Keith Moore wrote:
[I wrote:]
When customers of retail Internet service start demanding a NAT
standard, then that's when the IETF might want to think about
documenting the standard that the market seems to want.
here's the only thing that a NAT standard should say:

an intermediary MUST NOT alter the source or destination field in an IP
header.
an intermediary MUST NOT route an IP packet to other than its intended
destination.
an intermediary MUST NOT alter the payload of an IP packet.
I don't dispute this.  However, I will observe that customers of retail 
Internet service seem to rarely have much interest in whether their 
network intermediaries comply with this proposition.

And, your list is incomplete.  The NAT code I maintain does all of the 
things above that your proposal would explicitly forbid-- but it does a 
few other nasty things as well.  For example, 1) it *should* be 
rewriting IP datagram identifiers (but I haven't coded it yet), and 2) 
it hides path-MTU discovery black-holes by rewriting TCP MSS fields.

Basically, once you've committed to rewriting the forwarding 
information in an IP datagram, then it's open season on all manner of 
horrible opportunities for intermediaries to engage in Internet abuse.

You want to know what made my blood run cold in the latest release of 
the product's firmware?  I had to change it so that it would propose an 
impossible MRU in a PPPoE LCP negotiation.  Apparently, a lot of PPPoE 
implementations are happily proposing an MRU of 1500 octets, because 
there are a lot of PPPoE servers out there that will refuse to 
negotiate down to the more realistic value of 1492.  Consequently, when 
the product doesn't connect to a buggy PPPoE server, and every other 
product people try seems to work fine (as long as you don't stress test 
it), the customer blames the firmware that actually complies with the 
actual standard for refusing to work the way everyone else's 
non-compliant system works.

So yeah-- I'm very excited about the prospects of the IETF proposing 
standards.  I'm even more excited when they're standards that customers 
regard as actually valuable parts of their lifestyles.  I have yet to 
see a proposal for a NAT box spec that would seem like a valuable 
addition to the RFC library.  Including yours, Keith... no disrespect 
intended, honest.

--
j h woodyatt [EMAIL PROTECTED]
stop me before i rewrite your IP header again.

NAT box spec? (RE: myth of the great transition)

2003-06-18 Thread Harald Tveit Alvestrand 


--On tirsdag, juni 17, 2003 19:33:24 -0700 Hallam-Baker, Phillip 
[EMAIL PROTECTED] wrote:


On Tuesday, June 17, 2003, at 11:51  AM, Hallam-Baker, Phillip wrote:

 The key in my view is to work on the NAT vendors, instead
of viewing
 NAT
 boxes as an obstacle they should be seen for what they
really are, an
 essential and important part of the internet infrastructure.
you obviously don't write applications.
No, because I design and use applications I really wish that the IETF
had designed a decent NAT box spec rather than adopting the ostrich
position.
Phil,

at the risk of feeding into a long-burning flamewar:
when you say a decent NAT box spec, what do you think of?
As far as I can tell, a NAT box contains, over and above what it does 
because it's a router, a firewall or any other thing it might do:

- Address translation
- Application layer gatewaying
- Remote control of the NAT functionality (already being worked on in 
MIDCOM)

So what did you want a decent NAT box spec to say?

   Harald, genuinely curious

Re: NAT box spec? (RE: myth of the great transition)

2003-06-18 Thread Keith Moore 
 When customers of retail Internet service start demanding a NAT 
 standard, then that's when the IETF might want to think about 
 documenting the standard that the market seems to want.  

here's the only thing that a NAT standard should say:

an intermediary MUST NOT alter the source or destination field in an IP
header.

an intermediary MUST NOT route an IP packet to other than its intended
destination.

an intermediary MUST NOT alter the payload of an IP packet.