Subject: Re: (ngtrans) Shipworm obfuscation

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

On 9/28/02, Randy Bush wrote:

>> 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).
>

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
http://asomi.com/CaitlinBestler/

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 01 Oct 2002 11:22:19 -0700

Sorry for the delay on responding to Christian. I notice that Jim Bound has
also commented on this subject in the interim. I acknowledge Jim's opinion
that IPv4 multicast proliferation in 802.11 may not happen, but in my opinion
only time will tell. I disagree that Mobile IPv4 deployment needs to be
wrapped up with this discussion, however. Now to Christian's points:

Christian Huitema wrote:
 > You are making a case for adding an optional "RA multicast" to ISATAP.

No - I have made the case that the RA multicast feature of 6over4 can
be used to augment ISATAP. (The draft I cited previously uses language
consistent with this fact, and lists 6over4 as a normative reference.)
But, I could have just as easily made the case that the 6over4 multicast
features could augment *any* unicast mechanisms used over IPv4 as a link
layer - when an IPv4 multicast routing infrastructure exists, of course.

 > By the way, you should really how much data can be multicast efficiently
 > on a cellular network. We are observing that the quality of multicast
 > transmission over radio links is often very poor, especially if the
 > message requires more than one low level frame. The amount of data that
 > can be piggybacked on a wireless beacon is probably quite limited; a
 > simple RA may or may not fit, and you certainly won't have much space
 > for more data.

This depends entirely on the wireless MAC layer being used, but there are
really two issues wrapped up into one here and I confess to being responsible
for this from my original message. The first issue is whether MAC layer beacons
can be used to piggyback 6over4-encoded RFC 2461 router advertisements and,
again, this depends entirely on the MAC layer. The second issue is whether
sending 6over4 RAs as periodic beacons would provide an acceptable performance/
functionality tradeoff *whether or not* they are piggybacked on MAC layer
beacons.

Let's assume for the moment that a given media cannot support piggybacking,
in which case a potential optimization is not available. The question then
becomes whether the MAC layer provides a robust-enough link-level broadcast
capability to support 6over4 RAs as periodic beacons. For this discussion,
I think it useful to look at how MAC-layer broadcast is currently being
used in mobile ad-hoc routing.

Current trends in mobile ad-hoc routing environments include proactive neighbor
discovery protocols that send broadcast messages with fine granularity, e.g., one
message PER NODE per every 2-5 seconds. The neighbor discovery messages themselves
often contain the IP addresses of known neighbors, i.e., their size is directly
proportional to the number of neighbors which can grow quite large. Periodic
topology update messages also contribute a considerable amount of traffic to the
overhead, and these need to be multicast throughout the entire topology - not just
broadcast on the local link. Methods for efficient multicasting of topology updates
are at the heart of mobile ad-hoc routing protocol research.

Mobile ad-hoc network routing protocols are designed to work within the
very constraints of broadcast-capable wireless media, however. Most assume
best-effort delivery and low-moderate bit rate only; they also assume non-
negligible packet loss probability, e.g., due to hidden terminal interference.
Reasonable scaling properties up to 100's of nodes within the same bounded
region have been shown through experimental and simulation results. Clustering
techniques can also be used to extend scaling through aggregation and spatial
frequnecy reuse. Finally, much ongoing research is focused on MAC layer protocols
to enable better broadcast properties than existing technologies, e.g., IEEE 802.11.

The 6over4 RA beaconing process I have inferred entails a much more coarse-
grained scenario, e.g. one message every 5-10 seconds (or longer) PER BASE
STATION; one might reasonably expect the number of base stations within the
same bounded region to be relatively small. Thus, the amount of broadcast
channel bandwith required to support it would be down in the low level
noise when compared with proactive ad hoc routing protocols. Like the
topology update messages used in ad-hoc routing protocols, the RAs would
need to be multicast to the entire topology. But, the same efficient
multicast mechanisms designed for ad-hoc can be used for this purpose.

Fred
[email-masked]

---

From: "Michael Cole" <[email-masked]>
Date: Tue, 1 Oct 2002 19:11:19 -0400

I was getting the impression that the setup server's and the 
relay's addresses are different from page 14 of shipworm. Considering that 
I am a home user and that I am using Tiny Personal Firewall which is not an 
enterprise-class firewall, there seems to be something omitted form shipworm. 
Maybe I am missing something about how the  Teredo client gets the address 
of the (Teredo) relay.

There are also enterprise class NAT+firewall+gateway products such as 
Sygate Office Network. If we leave these guys out in the cold, there will be a 
problem. They are also NOT going to be crazy about having to replace their NAT 
software right off the bat in part because they paid a lot of money for it and 
the IPv4/IPv6 replacement gateway is not going to be cheap either. Very likely a 
lot of companies are going to want to stay at least 2 generations of software 
behind the leaders. This is much how every instability problem that I have had 
with Windows 95B can be traced to something other than the operating system such 
as a flaky power supply. I also have Windows 200 Professional on one of my other 
computers, but I did not dare expose it to the Internet until my Service Pack 3 
disk came in the mail.

There is also the problem that once somebody gets their hands on reliable 
hardware and software they do not want to change. One of the Y2K issues was that 
people were still using things like the IBM 1401 and the DEC PDP-8 because they 
are so reliable.

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

From: Christian Huitema  

To: ngtrans ;Michael Cole 

Sent: 9/29/2002 6:53:34 PM 

Subject: RE: (ngtrans) Shipworm 
obfuscation

I don't see how your message answers the first question we should ask 
before any new work:

"what are the scenarios in which a unified solution would be more useful 
than several separate

solutions?"

  _____  

From: Michael Cole [mailto:[email-masked] ] 

Sent: Sat 9/28/2002 10:42 PM 

To: ngtrans 

Subject: RE: (ngtrans) Shipworm obfuscation 

What I meant by a unified standard is that we have a set of problems where 
in order to translate an IPv4 address we also have to incorporate the port 
number. Shipworm is a good start, but I believe that it can be made into 
something more versatile to get around the problem that in some instances 
besides NATs, the port number has become a 16-bit extension of the IPv4 
address.

Usually, the only way to recan a can of worms is to use a bigger can. NATs 
and RFC 1918 have created these kinds of problems. For instance, the RFC 3056 
could be used with the Isatap suffix so as to concatenate a global IPv4 and a 
local IPv4, but that does not help when the port number must or should be 
incorporated in order to get the work done.

The other problem is that the BIGGEST obstacle to deployment of IPv6 is 
that most corporations want experience and they want people to get experience 
from an invisible gremlin named Not Me. It is going to take 15 years to overcome 
that obstacle. Any transition mechanism needs to be durable and has to get 
around IPv4 hardware and software that somebody refuses to replace because there 
are not enough experienced IPv6 people. I have seen a major company (Alcoa) 
spend $100,000 on recruiting costs in order to avoid $10,000 in training 
costs.

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

From: Bound, Jim   

To: Fred L. Templin ;Michael Cole 

Cc: [email-masked]  

Sent: 9/29/2002 12:52:22 AM 

Subject: RE: (ngtrans) Shipworm obfuscation

I would not assume we will get a unified box from the thought.  I 
believe doing a spec is fine.  I am not clear it is needed for a 
supplier to implement all this in a box and most likely by the time it was 
defined ISATAP, 6to4, and Teredo will be deployed.  6OVER4 is 
DEAD.  Not enough users use multicast in IPv4 to warrant the business 
investment is my reading for products I work on.

/jim

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

From: Michael Cole [mailto:[email-masked] ]

Sent: Friday, September 27, 2002 11:40 PM

To: Fred L. Templin

Cc: [email-masked] 

Subject: Re: (ngtrans) Shipworm obfuscation

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  mailto:[email-masked]    

To: [email-masked]   mailto:[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.

 

--- Michael Cole

--- [email-masked] 

--- EarthLink: It's your Internet.

 

--- Michael Cole

--- [email-masked] 

--- EarthLink: It's your Internet.