Subject: Re: Draft: PI addressing derived from AS numbers

From: "J. Noel Chiappa" <[email-masked]>
Date: Mon, 3 Feb 2003 20:15:24 -0500

> From: Brian E Carpenter <[email-masked]>

    > I feel that the challenge is actually not in the Internet Protocol
    > address at all. IPv6 *unmodified* is entirely capable of supporting a
    > namespace independent of topology

Syntax != Semantics.

Just because you have a single namespace that you can allocate both "where"
and "who" names from doesn't mean you're done.

Unless you start using multiple headers (which is sort of already specified,
which is why I like 16+16, although it has all the obvious "source routing"
security bugs), there's only a single IPv6 address field in "IPv6
*unmodified*", so it's kind of hard to do both with one field.

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Feb 2003 15:07:28 +0100

> and "who" names from doesn't mean you're done.

Of course, I didn't mean to imply otherwise.

> *unmodified*", so it's kind of hard to do both with one field.

I'm not sure I've seen the 16+16 draft. But it is my assumption that
any solution is going to involve an additional mapping stage
that we don't have today.

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 17:09:35 +0100 (CET)

> *unmodified*", so it's kind of hard to do both with one field.

HIP can help with the "source routing" security bugs.
One question in my mind is whether that type of approach requires 
IPsec protection of every packet, or if one can limit this to a subset
of the packets (like the TCP SYN/SYN-ACK exchange).

Another question, once we have the architectural 16+16 picture clear,
is whether it is possible to do "header compression" to avoid having 4*16
bytes of identifiers+locators in every packet.

A third question is whether one can make this work with both hosts doing
16+16 (which might provide a stronger security binding) and site border
routers doing it (which would be easier to deploy using existing IPv6
implementations in the hosts).

I'll stop now,
   Erik

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 21 Feb 2003 13:07:02 -0500

> HIP can help with the "source routing" security bugs.

AH can also do that without changes -- the trick for AH and HIP is
key management, as always with security gorp.

In fact, AH was designed to be able to authenticate *any* IP extension
header (or option).  ESP can only authenticate stuff inside the ESP 
payload.
This difference between AH and ESP (null-encryption) is not as widely
understood as maybe it ought to be.

> of the packets (like the TCP SYN/SYN-ACK exchange).

Unclear to me how one avoids cryptographic on each source-routed packet.
On the other hand, 16+16 or 8+8 doesn't necessarily involve 
source-routing.

> bytes of identifiers+locators in every packet.

The other approach would be to run with 8+8.  If 16+16 works, 8+8
can also work since they are architecturally the same.

> implementations in the hosts).

I don't follow that sentence.

Ran
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Feb 2003 16:59:53 +0100 (CET)

> On the other hand, 16+16 or 8+8 doesn't necessarily involve 

Sorry, I was reusing Noel's "source routing bugs" term.
The issue is with the decoupling of identifiers and locators opening up
a type of spoofing attack which isn't present when identifier=locator.
The nature of this is similar to source routing attacks, which is why
I think Noel was using that expression.

> I don't follow that sentence.

Assume you are going to do 16+16 with reasonable security.
One choice would be to have 16+16 addresses/headers end-to-end.
Another choice would be to have boxes in the middle (such as border routers)
add and remove the outer addresses/headers.
My question is whether this can be done.

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Feb 2003 19:01:07 +0100 (CET)

> My question is whether this can be done.

Why would we want to have two sets of addresses in any part of the
communication path? The identifiers can simply be replaced by locators
(and vice versa) between the TCP and IP layers. This could also be done
by external boxes if those aren't bothered by the state that must be
kept.

A solution where the identifier is present in each packet may be simpler
to implement, but only if there is no additional complexity for
authenticating the identifier, which seems unlikely.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Feb 2003 14:06:14 +0100 (CET)

> by external boxes if those aren't bothered by the state that must be

I think that conceptually they are all present in each packet.
Some form of end-to-end "header compression" can presumably remove the need
for the identifiers in every packet, but presumbly this is a function
of the state at the endpoints.

It would presumably be easier to maintain the compression state in
the transport protocols (due to fate sharing etc) than in a separate
entity, whether it is below transport in the endpoints or in a separate box.

> authenticating the identifier, which seems unlikely.

Good point.

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.

   Erik

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 25 Feb 2003 08:44:06 -0500

On Tuesday, Feb 25, 2003, at 08:06 America/Montreal, Erik Nordmark 
> entity, whether it is below transport in the endpoints or in a 

s/transport protocols/end systems/

Its not at all clear to me that such compression state belongs in 
TCP/UDP/SCTP
rather than being inside IP.  In practice, any IPv6 host has some amount
of IPv6 protocol state.  That is probably the right place for this 
information.

> contain the locators (at least until a locator changes) might be the

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.

Ran
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Feb 2003 06:26:25 -0800

So what I'm getting from this discussion is that 8+8 is too late but 
16+16 is too large???  I would agree that 16+16 is too large.  How about 
4+16?

Eliot

---

From: marcelo bagnulo <[email-masked]>
Date: 25 Feb 2003 17:20:06 +0100

Hi Iljitsch, Erik, 

On Mon, 2003-02-24 at 19:01, Iljitsch van Beijnum wrote:
> communication path?

I do not want to overload the requirements but i think that there are
some other relevant problems that could be addressed using the
separation of identifiers and locators.

In  a scheme that identifiers and locators are separated, i would guess
that identifiers belong to the identified part (i.e. end users) and
locators belong to the ISP. So,  PA is used  to preserve routing system
scalability.

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. Clearly, locators are also needed in
packets for routing.

Does any of this makes any sense? (If no is answered please explain)

Regards, marcelo

>  The identifiers can simply be replaced by locators
-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 26 Feb 2003 12:19:01 +0100

> 16+16 is too large???  I would agree that 16+16 is too large.  How 
> about 4+16?
>

I am still curious as to why people think that 16+16 would be any 
different to 8+8.

- kurtis -

---

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

> I am still curious as to why people think that 16+16 would be any

Because, like 4+16, it can coexist with plain 16. Whether people like
it or not, the product investments in RFC 2460 at this point oblige
any plausible solution to behave as an upgrade to plain 16.

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Feb 2003 10:06:15 -0500

On Wednesday, Feb 26, 2003, at 09:02 America/Montreal, Brian E 
Carpenter wrote:
>  Whether people like

I'm not persuaded that is true.  Certainly I know a lot of IPv6
deployed sites that are NOT taking the position above.

Ran

---

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

> deployed sites that are NOT taking the position above.

Are you saying you wouldn't mind significant changes in the IPv6 packet
format? This would essentially be IPv7.

In that case I have a few ideas...

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Feb 2003 11:03:22 -0500

On Wednesday, Feb 26, 2003, at 10:46 America/Montreal, Iljitsch van 
> format? This would essentially be IPv7.

There is some middle ground between "one can't change anything in 
RFC-2460"
and "essentially IPv7".  I should hope that someplace in that middle 
ground
sufficient manuevering room could be found.  Certainly I'm not 
advocating
dumping IPv6 wholesale, though I'm not above a tweak here or there to 
the
specs IFF it makes a sufficient improvement to be worth the pain.

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Feb 2003 17:03:58 +0100

> deployed sites that are NOT taking the position above.

I'm not talking about that. I'm talking about implementors. There is 
no way on earth existings stacks are going to get demolished and 
reconstructed. Even getting them enhanced will mean a lot of
heavy lifting. Please see requirements 3.2.2 and 3.2.3 in
the multi6 requirements draft. (If there's a way to make 8+8
meet those requirements, fine.)

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 26 Feb 2003 11:18:32 -0500

On Wednesday, Feb 26, 2003, at 11:03 America/Montreal, Brian E 
Carpenter wrote:
>  There is no way on earth existings stacks are going to get demolished 
> and
> heavy lifting.

I know of several significant implementers who would be willing to make
significant changes to their IPv6 stack, IFF it would have significant
improvements for IPv6.  Getting multi-homing into a scalable state would
be one example of a significant improvement.  Making mobility a 
first-order
property, rather than a "Mobile IP" add-on protocol, might be another 
one
(not sure).

Frankly, part of the implementers' willingness is caused by desire to 
see
their code get widely deployed operationally.  I've personally worked on
~4 different IPv6 implementations since 1995, and I don't see ANY way 
that
IPv6 will EVER be widely deployed given the current trajectory (i.e. 
there
is no significant win to migrating to IPv6 that is visible; IPv6 needs a
"killer feature", multi-homing or other routing improvements could be 
that,
the extant misleading claims of IPv4 address shortages is NOT such a 
feature).

As noted in a note earlier today, a significant change to IPv6 stacks
is one thing.  Throwing IPv6 out entirely is something entirely 
different;
I don't advocate the latter at all.

Ran
[email-masked]

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 27 Feb 2003 10:25:55 +0100

> any plausible solution to behave as an upgrade to plain 16.

Ok, I can see that. I was just under the (apparently mistaken) 
impression that people thought there was some superior architectural 
advantage with 16+16.

Best regards,

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 27 Feb 2003 10:49:10 +0100

>>  There is no way on earth existings stacks are going to get 
>> demolished and

I think you are right. However, I still think that we are trying to 
solve everything in one go. I think that we will have to go to a 8+8 or 
16+16 model, but not from day one. We will have to realize that we need 
to change things a bit at a time. This will most likely also mean that 
getting adoption for changes is easier. So besides working on the end 
outcome we should also be looking at how to get there.

- kurtis -

---

From: Tim Chown <[email-masked]>
Date: Thu, 27 Feb 2003 10:22:54 +0000

> impression that people thought there was some superior architectural 

Well, unless you could do something very clever with the "unused" 20 bits
in the v6 header... I suspect that's the only tweak that could get wide
acceptance (compared to suggestions to use DSCP's for multihoming, which
I personally don't feel comfortable with).   

Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Feb 2003 12:05:13 +0100 (CET)

On Thu, 27 Feb 2003, Kurt Erik Lindqvist wrote:

> > improvements for IPv6.  Getting multi-homing into a scalable state
> > would be one example of a significant improvement.  Making mobility a
> > first-order property, rather than a "Mobile IP" add-on protocol,
> > might be another one (not sure).

> outcome we should also be looking at how to get there.

It all depends on whether you're going to do incremental upgrades that
work well with existing stuff or if you're going to break existing
implementations. In the latter case, you should do everything in one go.

Apart from that I'm not all that concerned with the size of the steps
but rather their direction. We need to establish some long-term goals so
we can keep our eye on the prize (and other eye on the price) when
making those smaller steps. We don't want to paint ourselves into a
corner. (Arguably, we already have.)

My ultimate goal would be to make applications and transport protocols
independent of IP by allowing anything that's suitable for an identifier
(hostnames, crypto stuff) and leave the addresses/locators to lower
layers. An intermediate step could be middleboxes that replace PI
identifier addresses with PA locator addresses for outbound and the
other way around for inbound traffic. An intermediate step before that
would then be to use these PI identifiers in IPv4-like multihoming for a
limited time.

Iljitsch

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Feb 2003 12:32:03 -0500

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:
    RJ> On Tuesday, Feb 25, 2003, at 08:06 America/Montreal, Erik Nordmark
    RJ> wrote:
    >> It would presumably be easier to maintain the compression state in the
    >> transport protocols (due to fate sharing etc) than in a separate

    RJ> s/transport protocols/end systems/

    RJ> Its not at all clear to me that such compression state belongs in
    RJ> TCP/UDP/SCTP rather than being inside IP.  In practice, any IPv6 host
    RJ> has some amount of IPv6 protocol state.  That is probably the right
    RJ> place for this information.

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

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

  Gosh, this sure sounds like the packets ought look like:
	IPv6, AH, IPcomp-well-known-CPI, IPv6, TCP
               ^could be ESP-null
  The IPsec SPI contains all the state that you need. 

  I assume that we'll worry about how to map end system identifier to locator
later.
  
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 28 Feb 2003 08:33:59 -0500

On Wednesday, Feb 26, 2003, at 12:32 America/Montreal, Michael 
>   The IPsec SPI contains all the state that you need.

It is not at all clear to me that one needs to use AH/ESP on each data
packet in order to have protection equivalent to existing IPv4 packets
that are not using AH/ESP.

For example, one could imagine using a new ICMP message type to update
locator/identity bindings for sessions/flows that are already 
established
-- always using AH on that ICMP message type.

I see no need to tunnel IPv6-in-IPv6 normally.

I see no need for IPcomp-well-known-CPI normally.

So I'd suggest that a typical packet would look more like:

		IPv6(*), TCP

Where (*) is to note that minor tweaks might be needed, either
to the IPv6 base header or by adding an IPv6 Routing Header
or by some other mechanism, to support identity/locator separation.

Ran
[email-masked]