Subject: Re: (ngtrans) Shipworm obfuscation

From: "Michael Cole" <[email-masked]>
Date: Fri, 27 Sep 2002 23:39:47 -0400

A unified box definitely would make some things easier. Between the matter 
that cable ISPs have been using NATs and some wireless access points can engage 
in NAT-like behavior, there is the possibility of LAN-to-LAN NATs. Same for 
encryption boxes on LAN-to-LAN links. The protocol unification would have to 
provide for either coping with double NATting or having a way to avoid it or 
both.

Where there is a possibility of a long term island or isthmus of IPv4 
connectivity are things like wireless nodes and encryption boxes especially 
since the integrated circuit lifetime problem was solved starting with the 386. 
I have seen early LSI chips last about as long as industrial vacuum tubes.

----- Original Message ----- 

From: Fred L. 
Templin  

To: [email-masked] 

Sent: 9/27/2002 7:36:15 PM 

Subject: Re: (ngtrans) Shipworm 
obfuscation

Michael Cole wrote:

  It would also make a unified

  Shipworm+Isatap+6to4+6over4 box easier to implement.

                        ^^^^^^

I'm glad you mentioned this, because 6over4 seems to be getting lost 
in

the shuffle here as we discuss other mechanisms. I agree that a 
unified

solution is what we're after, but I would rearrange your grouping 
above

somewhat differently as follows:

   unified_solution = (6to4 + (teredo + isatap + 6over4))

Since 6to4 provides the global solution and the other mechanisms 
contribute

various aspects to the local solution, the "unification" really only needs 
to

occur among the components in the inner parentheses. I am all for 
unification,

but have sensed some resistence in others; perhaps the only bone of 
contention

is what to call the unified thing?

I have an idea: why don't we just do a (bis) on RFC 2529 and merge 
the

necessary features from teredo and isatap in with the existing 
features

of 6over4?  Then, just as it was in the old days:

   unified_solution = (6to4 + 6over4)

If this would make everyone happy, then maybe we can finally work 
together

on the details of the unification in a spirit of cooperation.

Comments?

Fred

[email-masked] 

--- Michael Cole

--- [email-masked] 

--- EarthLink: It's your Internet.

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Sep 2002 20:49:23 -0700

> cable ISPs have been using NATs

i am even more confused than usual.  as docsis is a layer two cpe, please
explain this.  thanks.

randy

---

From: Caitlin Bestler <[email-masked]>
Date: Sat, 28 Sep 2002 11:13:43 -0500

On 9/27/02, Randy Bush wrote:

>i am even more confused than usual.  as docsis is a layer
>two cpe, please explain this.  thanks.
>
>randy
>

A docsis cable modem is layer 2 device that is SNMP
controllable via an IP stack, and which can perform layer 4
filtering of packets. But it is not a router, it is a layer
2 device. If this makes sense to you, you obviously have
experience with drafting industry standards.

A Cable ISP also supports IP addresses on the other side of
the CPE. To the best of my knowledge, there are no cable
ISPs which will let you acquire your own C block and simply
advertise your router over their network.

Instead, the network behind the cable modem is generally
assigned IP addresses from a block owned by the Cable ISP.
This may be statically and/or via DHCP. The DHCP assignment
may be truly dynamic or actually static. The address
assigned  may be a public IP, or a private address relying
on NATting.

The Cable ISP also defines a default gateway, which the
customer must use. Packets destined for a different gateway
are likely to be filtered out.

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

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Sep 2002 09:25:15 -0700

> My DOCSIS cable modem seem overly invovled in looking at the L3
> payload it's carrying.

i am hearing different things in stereo.  it would be worth having
this explained.  are docsis modems l2, or l3, or a hack in between?

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Sep 2002 09:40:08 -0700

> A docsis cable modem is layer 2 device that is SNMP controllable
> via an IP stack, and which can perform layer 4 filtering of
> packets.

that there is a l3 control path is a side issue.  that it snoops
and can filter at l3 is a data path issue and is the meat of the
matter.  i.e. one has to configure it to allow any l3 traffic not
planned and provisioned by the isp(s).

so, are the l3 snooping filters and the head ends capable of being
configured for ipv6?

randy

---

From: Caitlin Bestler <[email-masked]>
Date: Sat, 28 Sep 2002 18:22:33 -0500

On 9/28/02, Randy Bush wrote:

>> controllable via an IP stack, and which can perform
>> layer 4 filtering of packets.
>
>that there is a l3 control path is a side issue.  that it
>snoops and can filter at l3 is a data path issue and is
>the meat of the matter.  i.e. one has to configure it to
>allow any l3 traffic not planned and provisioned by the
>isp(s).
>

The intent of the filter is to block all traffic not
specifically approved. Legitimate purposes include
preventing the Cable Modem from introducing forged packets
to the network. All source IP addresses will match a known
Cable Modem, and hence can be traced to a specific customer.

>so, are the l3 snooping filters and the head ends capable
>of being configured for ipv6?
>

The MIBs allow for IPv6 addresses.

However, it would be prudent to assume that the QA process
was more thorough when testing with IPv4 addresses.

Because Cable Modems can forward non-IP traffic, such as
IPX. There is a very good chance that virtually all CMs can
be enabled to forward *all* IPv6 traffic even if there is a
flaw in their IPv6 packet filtering.

Caitlin Bestler

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Sep 2002 16:46:20 -0700

> The MIBs allow for IPv6 addresses.

hence, if they saw demand (i.e. enough people being willing to
pay for services), the cable operator(s) could run something
like 6to4 at the head end until they have a v6-enabled inter-
head end backbone?

> was more thorough when testing with IPv4 addresses.

of course

randy