Subject: Headers

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Feb 2003 19:45:26 +0100

[doing some aggregation]

RJ Atkinson:
> > Perhaps providing a reasonably strong binding between the identifiers
> > and locators in some initial packet(s), and having subsequent packets
> > only contain the locators (at least until a locator changes) might 
> be the
> > right model.

> That might well be reasonable.  One would want to see the details 
> before
> drawing a firm conclusion, of course.

> In my book, "reasonably strong binding" means some form of 
> cryptographic
> authentication.

I'm imagining a situation (see my "transportzilla" posts from a while 
back for more details) where the application uses an identifier which 
doesn't have to be an address, and TCP and UDP use this identifier in 
the pseudo-header. IP only uses the locators. So there must be a 
mapping between the locators and the identifiers between IP and TCP. As 
long as each combination of { any source locator, source port, any 
destination locator, destination port } is unique on both ends, there 
shouldn't be any trouble finding the right source and destination 
identifiers on the destination host. Of course there is the minor 
detail of setting up all this state...

This should bind the identifiers to the locators strong enough without 
any per-packet overhead as long as the setup phase is well-secured. Of 
course there are still the traditional TCP weaknesses but the billions 
of packets flowing around the net every second tell us most people can 
live with this most of the time and there's always TLS and IPsec.

J. Noel Chiappa:
> One way to "include" the identifier in each packet implicitly (i.e. 
> make
> sure the packets get to the right endpoint) is to include the endpoint
> identifier in the transport "pseudo-header", so that you get a checksum
> failure if the packet gets to the wrong endpoint.

Yes. But: packets shouldn't end up at the wrong session anyway unless 
something is seriously broken and this provides no protection at all 
against someone who can intercept the communication as the TCP checksum 
is hardly a one-way hash.

> I hypothesized an small, short, endpoint identifier with scope local 
> to the
> destination (I called it an ESEL, for "endpoint selector") to 
> disambiguate
> when you have multiple endpoints at a single locator.

Wouldn't this be similar to a port number (for outgoing connections) or 
an IPsec SPI?

> I would suggest that 16+16 be done not with a complete second IPv6 
> header,
> but rather one of the routing headers (I forget the formal name). That 
> would
> make it somewhat smaller.

Which identifier do you need? The source or destination? The trouble is 
the 8 byte alignment in IPv6: this is enormously inconvenient when you 
need to add something that is also 8 byte aligned because you then need 
8 bytes just to say there is an extra header. (Lets remember this for 
IPv7: no 2^x sized addresses!) This means a second IPv6 header is the 
shortest way to add both a source and a destination identifier. So then 
we're tunneling.

> Anyway, why does header size matter that much? Those on slow links (< 
> 56K)
> will be using header compression anyway, so it doesn't really matter 
> for them
> since the average packet will have all that stuff compressed out 
> anyway, and
> for those on fast links, who cares about a few extra bytes?

Short answer: someone should! If we're going to do 2 IPv6 headers the 
additional 60 bytes per packet aren't going to persuade anyone to 
switch. The average IP packet size is around 500 bytes, so that's 10% 
of your bandwidth you're throwing away by switching. Header compression 
is great, but it doesn't solve everything. For instance, my iBook has 
RFC1323 extensions enabled by default. This makes the TCP header 12 
bytes longer (yeay!) but also unpredictable.

Also, all these headers at every layer add up. 11 Mbps wireless? Don't 
make me laugh: you're lucky if more than half is usable payload.

If we can accomplish the same functionality without the extra headers, 
we should do it without.

> Check out the average web page to see how many stupid little icons it 
> has on
> it, how many JavaScript files it loads, how many pop-up windows (with 
> their
> own images and Javascript) it loads, etc, etc. (Every Web page 
> designer ought
> to be sentenced by law to using a 28.8 modem for all their online 
> access...
> but I digress.)

So we should do basically the same thing, but then for the entire 
internet where everyone is forced to eat the extra overhead the next 15 
years or so? At least I have a choice when visiting websites, there are 
only a few flavors of IP around...

marcelo bagnulo:
> In order to preserve aggregation, renumbering is required when changing
> ISP, this is why end-sites like PI.

> Now, the separation of identifier and locator can help with this,
> simplifying re-homing events and renumbering. I guess that this
> separation can help in such events. Currently internal systems such as
> access lists, firewall use IP address for filtering, so that if the 
> site
> renumbers all these list have to be updated. If id-locator separation 
> is
> implemented, these systems can use identifiers, that belong to the end
> site, symplifying re-homing events. In order to do this, identifiers
> need to be carried in packets.

You can't take what's in a packet at face value: this information can 
be spoofed. I would rather have the firewalls take part in the session 
establishment procedure. Then you don't need the explicit identifiers 
as per the above.

Iljitsch

---

From: marcelo bagnulo <[email-masked]>
Date: 26 Feb 2003 11:18:48 +0100

> be spoofed.

Perhaps you could include enough info so you can check this.

>  
> I would rather have the firewalls take part in the session 
> establishment procedure. 

Wouldn't this preclude fault tolerance? I mean what happens if this path
is broken and the communication is re-routed through another firewall? I
mean this would introduce some of the issues of NAT.

Regards, marcelo

> Then you don't need the explicit identifiers 
> as per the above.
> 

-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Feb 2003 15:19:25 +0100

marcelo bagnulo wrote:
...
> mean this would introduce some of the issues of NAT.

Correct, or more generally the issues of any stateful middlebox.
The Internet doesn't have sessions, so middleboxes shouldn't
have session state.

However, it seems likely that any solution will involve either
a header rewrite or an encapsulation process. It is a design
requirement that any distributed state needed for this is soft
state, for the reasom Marcelo gives.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Feb 2003 16:41:00 +0100 (CET)

> Correct, or more generally the issues of any stateful middlebox.

Note that we are not requiring firewalls; other people are. If they fail
to require these boxes to handle the necessary state the right way,
that's their problem.

If a firewall is made part of the whole process at least we get to
implement some hooks for restoring the state if said firewall breaks.

> The Internet doesn't have sessions, so middleboxes shouldn't

If you want to be completely stateless, you need to include all the
identifying information in each packet. But this information is easily
spoofed, so you need additional authentication data. (Can't use IPsec
here as that has state.)

Fortunately, not much communication is stateless by necessity, it's just
implemented over stateless primitives because that has some advantages.

I wouldn't be against a situation where we have a stateful multihoming
protocol with low per-packet overhead and a stateless multihoming
protocol where everything is inside a single packet. However, I would be
against a multihoming solution where stateful protocols carry
information in each packet that is implied by the session state.