Subject: RE: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

From: "Tony Li" <[email-masked]>
Date: Mon, 5 May 2003 00:22:42 -0700

We also run into the issue of doing an identifier to locator
mapping.  If the identifier is a random value, then this
would be 'challenging'.  However, if this is a 64 bit
administratively assigned number, then we have both global
uniqueness and hierarchical search capability.

Tony

|    -----Original Message-----
|    From: Brian E Carpenter [mailto:[email-masked]] 
|    Sent: Monday, May 05, 2003 12:06 AM
|    To: Peter Tattam
|    Cc: [email-masked]
|    Subject: GSE IDs [Re: IETF multihoming powder: just add 
|    IPv6 and stir]
|    
|    
|    Peter Tattam wrote:
|    ...
|    > >
|    > > 3) We know from previous discussion that 64 bits is 
|    too short for a
|    > > randomly assigned global space;
|    > 
|    > I thought we were talking about a M + S + 64 bits 
|    address space where the M
|    > bits can be guaranteed globally unique and the S bits 
|    are managed by the site.
|    > For the purposes of global routing, this is unique 
|    enough to guarantee no
|    > collisions.  The uniqueness of the 64 bits within the 
|    local segment are managed
|    > by existing mechanisms of address autoconfig.
|    
|    That isn't the only requirement. If the M is mutable and 
|    the S has no 
|    particular reason to be unique, then if you have a set of peers 
|    intercommunicating, you've only got the 64 bit IDs 
|    available to act as 
|    unique IDs for transport end-point and security end-point 
|    identification.
|    
|    So there is a strong requirement that the 64 bit IDs be 
|    unique within
|    any set of intercommunicating peers. (In the case of TCP, 
|    the set has
|    two members; in the case of FTP it's any number, by use of the PORT
|    command.) 
|    
|       Brian
|    
|

---

From: "Tony Li" <[email-masked]>
Date: Mon, 5 May 2003 15:46:59 -0700

|    The focus on the site misses an important point. Computers 
|    are often
|    multi-homed to several sites, e.g. WiFi and GPRS. If you 
|    do something as
|    radical as changing the behavior of TCP, then you want a 
|    solution that
|    handles host multi-homing as well as site multi-homing. 
|    But then you
|    cannot expect that all the "locators" that carry packets 
|    to a single
|    TCP++ solution belong to the same aggregate.
|    
|    In the site multi-homing case, you must also be concerned 
|    with privacy
|    issues. You should not force multi-homed computers to 
|    attach the same
|    "global identifier" tag in all of their IP addresses, and 
|    you may expect
|    privacy advocates to forcefully remind you if you ignore 
|    that point. 

I don't believe that that's a serious issue, but if those same
folks want the full advantages of being a multi-homed host, then
something has to give.  The correspondent host can only work with
information that is disclosed.  Without that, the host would
appear to be multiple independent hosts.  

Tony

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 5 May 2003 17:52:49 -0700

> appear to be multiple independent hosts.

Notifying the correspondent host is fine, provided there is a way to
control it. Notifying the network is not.

-- Christian Huitema

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 8 May 2003 13:01:00 -0400

> From: "Bound, Jim" <[email-masked]>

    > 8+8 (my preferred term for GSE)

The two are fairly different, actually.

8+8 was originally proposed by Dave Clark, and it was splitting the IPv6
address into two fields, a 64-bit globally unique identifier in the low part,
and a locator in the high part.

GSE was an enhancement to that done by Mike O'Dell in which the high order
parts (of both source and destination) were massaged by border routers to
achieve various things. It brings a number of additional capabilities, but at
the cost of making the location<->identity binding even harder to secure.
(Unless you just throw your hands in the air and use authentication on all
packets, at which point the address becomes irrelevant.)

	Noel

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 8 May 2003 13:19:19 -0400

Agreed. In the meeting I was in Mike called it 8+8 to but your note is
accurate.
Thanks
/jim

> -----Original Message-----
> From: J. Noel Chiappa [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2003 1:01 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: GSE IDs [Re: IETF multihoming powder: just add 
> IPv6 and stir]
> 
> 
> address into two fields, a 64-bit globally unique identifier 
> in the low part, and a locator in the high part.
> 
> GSE was an enhancement to that done by Mike O'Dell in which 
> the high order parts (of both source and destination) were 
> massaged by border routers to achieve various things. It 
> brings a number of additional capabilities, but at the cost 
> of making the location<->identity binding even harder to 
> secure. (Unless you just throw your hands in the air and use 
> authentication on all packets, at which point the address 
> becomes irrelevant.)
> 
> 	Noel
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 8 May 2003 15:15:50 -0400

Dave,

> On Thursday, May 8, 2003, at 06:47  AM, Bound, Jim wrote:
> > I am also not clear on rewrite of headers in transit is 
> going to fly 
> > in some cases I can think of as use case and one example is the 
> > military tactical operations case, which for me is one area 
> I work on 
> > and care about as one of my roles working with users.
> 
> I'd be interested in understanding these cases better.  From my 
> perspective, what happens to my packet headers after they leave my 
> machine is completely irrelevant as long as they get put back 
> together 
> into something that will pass the checksum on the destination host.

If I am communicating with two command centers for mission critical
operation I want a knob that says I trust NO ONE and NO ONE is to
rewrite my headers but only forward operations.  Having a routing header
type would at least track that operation within the context of the
datagram.  Also cases where the entire IP datagram is compressed.  Cases
where all below the Header and DST/HOP-BY-HOP operations is ecrypted and
I do not want to trust any path to rewrite incorrectly where the end
result of that error are dead people.

> > I believe if we rewrite headers we need to swap them into 
> new routing 
> > header type for IPv6 too, which will remove going to the 
> DNS, LDAP, or 
> > MPLS database to get back to the end node.  I view this feature as 
> > keeping a history of location that is important.
> 
If I save the orgininal loc+id in route header I can pass it along and
likewise use it to pass it back.  MHAP could use this feature too.

/jim
> 
> > Probably also need to think about identity changing from say system 
> > crash, neighbor discovery DAD collision (after the fact of 
> solicited 
> > node multicast which I have seen in the real world).
> 
> The appoach I've been thinking about does not touch the 
> identity of the 
> end system as determined via DAD or any other mechanism -- a 
> packet has 
> a site identity value in the top 48 bits of the destination address 
> that maps into an aggregatable locator when the packet leaves the 
> source site and gets remapped from the locator back into the site 
> identity when it arrives at the destination site.
> 
> > I know I am going far to down in details sorry :--)
> 
> I like details when trying to figure out if a particular (arguably 
> radical) approach will fly.
> 
> Rgds,
> -drc
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 9 May 2003 08:00:05 -0400

There is no reason to do this based on my previous mail.
/jim

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Friday, May 09, 2003 4:11 AM
> To: David Conrad
> Cc: [email-masked]
> Subject: Re: GSE IDs [Re: IETF multihoming powder: just add 
> IPv6 and stir]
> 
> 
> David Conrad wrote:
> > 
> > Brian,
> > 
> > On Wednesday, May 7, 2003, at 02:08  AM, Brian E Carpenter wrote:
> > >> Or you simply rewrite the first 48 bits when the packet 
> traverses 
> > >> the border into the destination site with the same value 
> the packet 
> > >> had prior to traversing the border of the source site.
> > > This was not part of any GSE proposal I ever saw,
> > 
> > Different terminology would be helpful.  Of course, this implies my 
> > messages on this topic have been whistling past people for the last 
> > two months.
> > 
> > > and it involves stateful
> > > distribution of mapping information.
> > 
> > Yes.  In one approach, a mapping of a globally unique 48 
> bit value to 
> > a set of other globally unique 48 bit values where that distributed 
> > lookup of that mapping occurs at the source border only.
> > 
> > > A very different beast from GSE,
> > > and it sets off my stateful=bad alarm.
> > 
> > Your alarm must go off continually today,  as the mapping 
> is more or 
> > less equivalent to either the DNS or routing tables, 
> depending on your 
> > point of view.
> 
> Right, and we know that faulty DNS setups cause connectivity 
> glitches on a daily basis - because DNS state is created and 
> managed by every site worthy of the name, and mistakes are 
> inevitable. We also had years of 
> connectivity glitches caused by BGP4 configuration errors - 
> most operators 
> seem to have that figured out now, but it was bad for a 
> while. Introducing 
> a third distributed state mechanism that will be critical for 
> connectivity 
> is indeed a big step. 
> 
>    Brian
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 9 May 2003 09:35:46 -0400

> On vrijdag, mei 9, 2003, at 14:05 Europe/Amsterdam, Bound, Jim wrote:
> 
> > By storing the end nodes in a routing header all other location can 
> > change enroute. This is completely stateless.
> 
> Not really. Someone must know to put in the routing header at some 
> point.

We build a dst option that informs the router the host did this so the
routers don't have to mess with it.  Or just but it in as dst option.
Or as new ext header.  I don't care how.

> 
> And this doesn't provide the functionality we need. Assume ISP A can 
> reach destination X but ISP B can't. In this case, the source must 
> transmit the packet over A. Transmitting it over B isn't 
> going to yield 
> useful results, regardless of the presence of routing headers.

This is not what I am addressing and orthogonal  However we get the
packet to the dst whether thru A or B the return address of the node is
required.  I want to avoid stateful looks in the path back to the
orginal, by last hop router to the dst, or by the receiving node as one
option for multi6.  

Or it can be kept in FINAL DST option within IPv6 too.  That way only
the receiving end node would ever see it and routers would not care. 

> 
> Also, we can't assume that users will universally prefer a stateless 
> solution with per-packet overhead over a stateful one that 
> doesn't have 
> extra overhead.

I can as one solution and that is my proposal for a stateless solution
as enhancement and use of the extensibility of IPv6.

> 
> I think state in the endpoints is perfectly acceptable. If 
> people want 
> central control over their multihoming and/or they want to 
> multihome-enable unmodified hosts by implementing the multihoming 
> functionality in a middlebox, having state in this middlebox 
> would also 
> be acceptable, especially if it's "soft state" that can be recreated 
> without breaking sessions if the middlebox fails. NAT shows 
> that it is 
> possible to build middleboxes that keep lots of state.

NAT is an abortion to networking that is not worthy of any response from
me it is almost as bad as the invention of bridges.

But if folks want state in the middleboxes that is fine I am proposing
another fix using the network computer science use of overloading,
extensibility of the datum being carried, and principles of cohesion
(close proximity) for indirection back to the end node. It also causes
no processing by ASICs in routers or processing.  It is used by the
receiving end node to respond to the destination.  It is similar in
property and architecture as the Home Address Option in Mobile IPv6, but
not exactly.  I believe it has less overhead too.

This way we can define the semantics of the 128bits architecturally to
support loc+ID and how to route packets across a inter-network of
topology and not have to worry about what the loc+id was for the
original node it becomes a non-issue.

Security for this is now well understood to apply what is required here
from MIPv6, HIP, AAA, and DNSSEC principles in those cases.  But has to
be clearly worked out.

If you don't like it that is fine but I would like to hear from others
on this list and the WG if that is ok with you?

I assume the answer is yes or you and I can go offline and discuss IETF
process?

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 9 May 2003 09:47:08 -0400

I went to an industry session yesterday in New England that discussed
blades, switches, 10gbE and beyond.  The IPv6 PMTU is large and capable.
I believe adding 128bits at original node idea to a DST, EXT option will
not kill the Internet or fast path for any ASICs I am looking at now
(not for routing but host IP / IPsec offload engines for prototype and
research on day job).  Just as note.  Also routing header is not a good
idea that was just off the top of the head.  EXT or DST option would the
way to go and be transparent to routers which is one of my goals.

/jim

> Sent: Friday, May 09, 2003 9:09 AM
> To: Iljitsch van Beijnum
> Cc: Bound, Jim; [email-masked]
> Iljitsch van Beijnum wrote:
> > ... NAT shows that it is
> and the failure modes associated with NATs show why
> this is a really bad idea. But even NATs keep that state 
> reasonably local; it doesn't have to be known by magic to an 
> anti-NAT at the other end.
> 
> Iljitsch, the big hole in your -00 draft is that is doesn't
> at all discuss the magic needed to distribute mapping state
> and keep it fresh. As I think I already said, this is why we 
> never pursued the map-and-encap proposal some years ago- it's 
> not a side issue, it's *the* issue in this class of 
> solutions, and it is the fundamental difference from 8+8/GSE.
> 
> I believe MHAP does discuss this question. And as Jim said, 
> there are stateless solutions, but that means adding bits to 
> the packet.
> 
>   Brian
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 9 May 2003 10:09:30 -0400

ALso this is just one infitesimal piece to multi6 to solve "keeping the
orginal node IP delivery address on the LAN" (using old standard terms
on purpose).  Possibly what we have to do for multi6 is break the
problem area into multiple pieces that need resolution instead of trying
to solve it as huge glob all at once and part of what has been holding
us up.

For example why not agree on what loc is equivalent to and how many bits
and ID for semantics?  Then go to next step.  If it breaks we
reevaluate.

That way bright people here can be working on specific tasks.  In fact
different bright people can go off and work on different aspects.

Then each with solution can look at those parts for their favorite
solution HIP, MHAP, MIPv6-LIKE.

/jim

> From: Bound, Jim 
> Sent: Friday, May 09, 2003 9:47 AM
> To: Brian E Carpenter; Iljitsch van Beijnum
> Cc: [email-masked]
> I went to an industry session yesterday in New England that 
> discussed blades, switches, 10gbE and beyond.  The IPv6 PMTU 
> is large and capable. I believe adding 128bits at original 
> node idea to a DST, EXT option will not kill the Internet or 
> fast path for any ASICs I am looking at now (not for routing 
> but host IP / IPsec offload engines for prototype and 
> research on day job).  Just as note.  Also routing header is 
> not a good idea that was just off the top of the head.  EXT 
> or DST option would the way to go and be transparent to 
> routers which is one of my goals.
> 
> /jim
> 
> > Iljitsch, the big hole in your -00 draft is that is doesn't at all 
> > discuss the magic needed to distribute mapping state and keep it 
> > fresh. As I think I already said, this is why we never pursued the 
> > map-and-encap proposal some years ago- it's not a side issue, it's 
> > *the* issue in this class of solutions, and it is the fundamental 
> > difference from 8+8/GSE.
> >

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 9 May 2003 10:26:28 -0400

I think this is formally called a spriral engineering process using the
E letter in IETF :-)

/jim

> Sent: Friday, May 09, 2003 10:10 AM
> ALso this is just one infitesimal piece to multi6 to solve 
> "keeping the orginal node IP delivery address on the LAN" 
> (using old standard terms on purpose).  Possibly what we have 
> to do for multi6 is break the problem area into multiple 
> pieces that need resolution instead of trying to solve it as 
> huge glob all at once and part of what has been holding us up.
> 
> For example why not agree on what loc is equivalent to and 
> how many bits and ID for semantics?  Then go to next step.  
> If it breaks we reevaluate.
> 
> That way bright people here can be working on specific tasks. 
>  In fact different bright people can go off and work on 
> different aspects.
> 
> Then each with solution can look at those parts for their 
> favorite solution HIP, MHAP, MIPv6-LIKE.
> 
> /jim
> 
> reasonably 
> > > local; it doesn't have to be known by magic to an anti-NAT at the 
> > > other end.
> > > 
> > > I believe MHAP does discuss this question. And as Jim said, there 
> > > are stateless solutions, but that means adding bits to the packet.
> > > 
> > >   Brian
> > > 
> > 
> > 
> 
>

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 9 May 2003 12:17:09 -0400

> NAT is an abortion to networking that is not worthy of any response
    > from me it is almost as bad as the invention of bridges. 

Funny you should put it that way - I've always thought that my inability to
see how useful bridges would be (within a certain limied context), and my
opposition to doing one, was the single biggest technical mistake I made
during my association with Proteon, and one of the biggest causes of their
loss to Cisco.

But this is all irrelevant to Multi6, so I'll stop there, and instead comment
on something relevant (next message).

	Noel

---

From: "Tony Li" <[email-masked]>
Date: Fri, 9 May 2003 11:13:03 -0700

In the words of Kirk Lougheed: don't fall in love with your
technology.

Tony

|    -----Original Message-----
|    From: J. Noel Chiappa [mailto:[email-masked]] 
|    Sent: Friday, May 09, 2003 9:17 AM
|    To: [email-masked]
|    Cc: [email-masked]
|    Subject: RE: GSE IDs [Re: IETF multihoming powder: just 
|    add IPv6 and stir]
|    
|    
|        > From: "Bound, Jim" <[email-masked]>
|    
|        > NAT is an abortion to networking that is not worthy 
|    of any response
|        > from me it is almost as bad as the invention of bridges. 
|    
|    Funny you should put it that way - I've always thought 
|    that my inability to
|    see how useful bridges would be (within a certain limied 
|    context), and my
|    opposition to doing one, was the single biggest technical 
|    mistake I made
|    during my association with Proteon, and one of the biggest 
|    causes of their
|    loss to Cisco.
|    
|    But this is all irrelevant to Multi6, so I'll stop there, 
|    and instead comment
|    on something relevant (next message).
|    
|    	Noel
|    
|

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 11 May 2003 05:02:10 -0400

Pekka,

Didn't you have to keep as HIT cache on the end host?  Also I have read
the updated drafts and now I will say after much thought I am not clear
the pain for HIP is worth it and it will take a long time to sort this
out as IP stack developer.  THere will be much needed change on end host
and in the core of layer and I am not clear it is a big win.  And I like
the idea of IP adddreses used for IPsec identifiers totally.  It keeps
us all honest about  e2e in relation to the IP header.  I view HIP like
my work on the offload of IP stackes to NICs.  It will take much
thought.  But I think it is heing oversold completely.

For IPsec can we go offline we must make this an extension not a change
or it will not fly for a long time for implementation?

thanks
/jim

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Friday, May 09, 2003 7:11 AM
> To: Bound, Jim
> Cc: [email-masked]
> Jim,
> Bound, Jim wrote:
> > Yes the HIP SPI could use the low order 64 bits but I want to read 
> > updates from Pekka N. just sent out for arch-03.  I am also unclear 
> > the HIP code changes to our transport layers or at the IP 
> layers will 
> > be done by what time frame.
> 
> HIP, in the way we implement it today, does not require any 
> changes to the transport layers at all, or to the IP layer in 
> anywhere else but at the end-hosts.  That is, of course, not 
> the only way to implement HIP, and it is probably also 
> possible to "distribute" HIP between an end-host and a middle 
> box, resulting in something that resembles MHAP.
> 
> In our current implementation, the only changes in the
> kernel are in IPsec ESP code.  All the rest is in user
> level, and the user level deamon dynamically modifies the
> IPsec SPD and SA entries to implement mobility.
> 
> Implementing multi-homing will require more extensive changes 
> to IPsec or elsewhere in the kernel.  We are still thinking 
> on how to do that.  Basically, we need to implement 
> destination address selection somewhere in the kernel.  (At 
> this stage we will be ignoring the actual selection 
> algorithm, and concentrate on the architecture:  Where to 
> "rewrite" the HIT into an IP address, and how to select the 
> right destination (and source)
> address(es).)
> 
> --Pekka Nikander
> 
>