Subject: (ngtrans) Shipworm obfuscation

From: "Michael Cole" <[email-masked]>
Date: Thu, 26 Sep 2002 23:17:21 -0400

Why not have a flag bit that indicates whether the address are in their 
normal state or in the 1s complement state? Seems to me that there are enough 
flag bits to do this. This way, 80% or whatever instances of Shipworm will be 
easier to debug. It would also make a unified Shipworm+Isatap+6to4+6over4 box 
easier to implement.

--- Michael Cole

--- [email-masked] 

--- EarthLink: It's your Internet.

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 27 Sep 2002 00:32:39 -0500

> 
> Why not have a flag bit that indicates whether the address are in
> their normal state or in the 1s complement state? Seems to me that
> there are enough flag bits to do this. This way, 80% or whatever
> instances of Shipworm will be easier to debug. It would also make a
> unified Shipworm+Isatap+6to4+6over4 box easier to implement.
> 

I doubt that the objection to the obfuscation had anything to do with the
processing overhead of XORing 48 bits. Rather, I presume, it was a simple
objection to the idea of obfuscating that which should be opaque. There should
be no need to hide the IP address from a NAT, because the NAT has been given no
reason to examine that payload. More importantly it has been given no authority
to do so. A NAT is network equipment -- except when the IP payload has been
explicitly identified as containing addresses (such as FTP) it MUST carry the
payload unmodified. You do not want the postman even reading your mail, let
alone modifying it.

The implementation of the feature is trivial. Placing an option around it only
makes it even more complex, and does nothing to eliminate the valid theoretical
objections.

However, these are theoretical objections. And while I agree with them, I am
more opposed to making changes in any protocol that has deployed base without a
justification. It means an entire generation of servers having to check flags as
to whether this is the old format or the new format. Its simpler to just stick
with the old format.

The obfuscated bits can still be justified as a measure to reduce the number of
false positives in diagnostic network analyzers, and for historic compatability.

The only change that i can see as being worthwhile might be some wording
cleanups to avoid any chance of an RFC being interpreted as even hinting that an
unauthorized modification of payload is acceptable NAT behavior.

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 13:05:15 -0400

> There should be no need to hide the IP address from a NAT, because the 
> NAT has been given no reason to examine that payload. More importantly 
> it has been given no authority to do so. A NAT is network equipment -- 
> except when the IP payload has been explicitly identified as containing 
> addresses (such as FTP) it MUST carry the payload unmodified.

NATs don't have any business modifying the IP header either, nor 
recomputing the IP checksum.  NATs violate IP right and left.

The bottom line is that the NAT vendors don't care how many things 
they break, as long as there are suckers willing to buy their products.

Keith

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 27 Sep 2002 12:31:19 -0500

On 9/27/02, Keith Moore wrote:

>> There should be no need to hide the IP address from a
>> NAT, because the NAT has been given no reason to examine
>> that payload. More importantly it has been given no
>> authority to do so. A NAT is network equipment -- except
>> when the IP payload has been explicitly identified as
>> containing addresses (such as FTP) it MUST carry the
>> payload unmodified.
>
>NATs don't have any business modifying the IP header
>either, nor recomputing the IP checksum.  NATs violate IP
>right and left.
>

The 'fool' who installed the NAT knew, or should have known,
that the device would modify IP headers and would modify the
control payload of certain specific upper layer protocols
such as FTP.

Hence these changes are authorized, whether you believe such
authorization was given prudently or not.

Unauthorized modification of the IP payload, I hope you
would agree, is far worse.

NATs, whatever your opinion of them, are an integral part of
the deployed IPv4 network. Their authorized and recognized
functionality must be respected as part of any IPv4/IPv6
interoperability.

That is a totally different question as to whether Teredo
should accomodate practices that, if they truly exist, can
only be classified as bugs. There is no 'feature' that they
could be implementing that anyone, even a 'fool' who
installs a NAT, would consent to.

Caitlin Bestler
http://asomi.com/CaitlinBestler/

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 13:46:54 -0400

> control payload of certain specific upper layer protocols

such a 'fool' could have as easily known that the NAT would modify
the IP payload.  whether the 'fool' understands the consequences
of either action is a separate question.  a lot of 'fools' have 
learned the hard way.

the reality is that once you build a NAT you immediately find that
it needs to modify payloads to allow even the most common applications
to work.  and no matter how smart you try to make your NAT, how many 
tricks you teach it, it will still break applications.  so the NAT 
vendors and their customers start blaming the apps for the problems 
that they caused.

there is *no* reasonable bound on NAT behavior because NAT behavior
is inherently unreasonable - it violates fundamental assumptions
of the IP architecture.

> functionality must be respected as part of any IPv4/IPv6

that's simply garbage.   the fact that NATs exist must be acknowledged.
the reasons that NATs were deployed must be understood and respected.
but we also need to recognize that NATs are an aberration and that
attempts to reconcile the architecture with NATs are doomed to failure.
the most that you will acheive by trying to incorporate NATs into the
architecture is to shift the problems that they cause to somebody
else (e.g. applications developers) who aren't in a position to solve
them either.

Keith