Subject: GSE

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 16 Feb 2003 21:51:09 +0100

Ok, I have re-read Mike O'Dells old draft from 1997. Can someone remind 
me what the reasons for not going with this was?

(Running for cover)

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Feb 2003 00:08:52 +0100 (CET)

> (Running for cover)

I wasn't around then, but the two main reasons for not raising it from
the dead would be:

- the draft as-is doesn't provide any actual multihoming benefits
- how can we make the lower 64 bits of the address globally unique

---

From: Eliot Lear <[email-masked]>
Date: Sun, 16 Feb 2003 15:15:04 -0800

> - the draft as-is doesn't provide any actual multihoming benefits

The point of the draft was that multihomed enterprises wouldn't ever be 
advertised into the dfz.  If a site wanted to multihome it would have 
address prefixes from two providers, and those would get stamped on packets.

> - how can we make the lower 64 bits of the address globally unique

The same way we do with 32 bits.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Feb 2003 00:22:31 +0100 (CET)

> advertised into the dfz.

Yes, it does that. But it doesn't give the multihomer transparent
failover (or even failover of any kind). I'm sure that once we agree on
the requirements GSE can't meet them.  :-)

> The same way we do with 32 bits.

Exit stateless autoconfig... I'm not even mentioning security.

If we want to do something GSE-like we might as well start from scratch.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 16 Feb 2003 22:56:19 -0800

Iljitsch,

> the requirements GSE can't meet them.  :-)

The draft was short on specifics for failover, as I recall, but so long 
as you had some connectivity between gateways it should have been 
possible to failover in a stateless way.  As to TCP I personally would 
have only used the lower 64 for the pseudo-header, just as with HIP you 
would use the HIT.  The big deal is that the host implementation would 
need to understand that the upper half and lower half would have to be 
processed quite differently.

> Exit stateless autoconfig... I'm not even mentioning security.

I suspect we differ substantially on where we think requirements should 
go.  Stateless autoconfig isn't my top feature requirement.  Scaling to 
more robust connectivity is.  There was an "analysis" of GSE security. 
However, Steve Bellovin didn't agree with it.  I do not recall the 
specifics.

This is not to say that GSE had all the answers.  It needed work.  For 
instance, route selection and failover did need some amount of fleshing 
out.  But I believe it suffered a premature death.

Eliot

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 Feb 2003 10:15:25 +0100

> - how can we make the lower 64 bits of the address globally unique

Before my mailbox fills up further - I specifically asked why this was 
killed back in 1997.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 Feb 2003 10:18:19 +0100

> the requirements GSE can't meet them.  :-)

Why wouldn't it?

> If we want to do something GSE-like we might as well start from 

Might not be such a bad idea.

- kurtis -

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Feb 2003 09:36:59 +0000

> Might not be such a bad idea.

Well, get started on IPv7 and let us know what you have in 2012 :)

Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Feb 2003 10:50:37 +0100 (CET)

On Mon, 17 Feb 2003, Kurt Erik Lindqvist wrote:

> > I'm sure that once we agree on the requirements GSE can't meet them.  :-)

> Why wouldn't it?

No failover. If a host as A::1 and B::1 and I select A::1 but then this
path goes down, GSE doesn't tell me what I should do. But I guess if
we're going to overhaul TCP anyway (as is needed for GSE) we can fix
this too. Another problem: how do I prevent someone from using C::1 and
stealing A::1/B::1's sessions?

Doing it the MHAP way and replace the addresses in transit makes more
sense as it doesn't require changes to higher layers and the explicit
search-and-replace operation makes security easier. Or use implicit
rather than explicit identifiers so you only have to negotiate some
stuff at the start of the session.

I can't help you with your original question about GSE as I wasn't
around in IETF circles in 1997.  :-)

---

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

Hi Kurtis,

I guess that the long answer to your question can be found at:

draft-ietf-ipngwg-esd-analysis-04 

(I can send it if anybody is interested)

Regards, marcelo

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Feb 2003 12:14:46 +0100

However, the main concerns that held it up at the time were
about security.  You probably want to get hold of
draft-ietf-ipngwg-esd-analysis-05.txt (I think -05 was the last
version.)

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: Randy Bush <[email-masked]>
Date: Mon, 17 Feb 2003 04:37:04 -0800

> Before my mailbox fills up further - I specifically asked why this was 

v6 protocol designers claimed, in his absence, that smb said there were
security issues.  according to smb, he made no such claim.

randy

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 17 Feb 2003 08:04:53 -0500

On Monday, Feb 17, 2003, at 01:56 America/Montreal, Eliot Lear wrote:
> There was an "analysis" of GSE security. However, Steve Bellovin
> didn't agree with it.  I do not recall the specifics.

Correction:		The IAB (at the time, smb and other folks) and the IESG 
(jis & ml)
				and several respected Security Directorate folks all agreed
				that the claimed "analysis" was not factually correct.

> instance, route selection and failover did need some amount of 
> fleshing out.  But I believe it suffered a premature death.

Regardless of the history, it would not hurt for folks to study the 
concepts
behind it.  I will *beg* that we avoid the usual flame-fest that erupts 
when
the letters "GSE" are mentioned in an IPv6 context.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 17 Feb 2003 08:07:43 -0500

On Monday, Feb 17, 2003, at 04:50 America/Montreal, Iljitsch van 
Beijnum wrote:
> No ...

O'Dell's GSE I-D is mostly an architecture document, not a protocol 
spec.
So of course MANY implementation-details are not specified in the old 
GSE I-Ds.
The absence of implementation details in an architecture document
doesn't prove anything either way about GSE's suitability for 
multi-homing
in the multi6 context.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 17 Feb 2003 08:11:40 -0500

On Monday, Feb 17, 2003, at 05:44 America/Montreal, marcelo bagnulo 
wrote:

> draft-ietf-ipngwg-esd-analysis-*.txt

That draft was never published as an RFC mostly because the IESG, IAB,
and several IETF Security Directorate members believed that it was not
factually correct.  The biggest issue is that it does not describe
the actual GSE/8+8 proposal accurately -- so the criticisms are of
something not quite the same as GSE/8+8.  This is NOT to imply that
the IESG, IAB, or other folks thought that GSE/8+8 was without
problems -- merely that the above draft was not on-target in its claims.

So folks should add a lot of salt when reading that draft.

Please lets move forward on multi6, rather than revisiting painful old
IPng WG history here.

Ran

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Feb 2003 09:19:08 -0800

Dr. Bellovin's analysis can be found at the following URL:

http://www.research.att.com/~smb/papers/esd-secure.txt

---

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

> me what the reasons for not going with this was?

Part of it being fear of the unknown and doing something so radical to
IPv6.
Part of it being some technical aspects (such as the impact of not
having a checksum on the source locator causing new failures,
and security issues related to relaxing the binding between identifiers
and locators). 
An attampt to capture the technical issues is in
http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-ipngwg-esd-analysis-05.txt
(Yes, www.ietf.org can search across all documents
at the internet drafts web page.)

Note that the security issues due to the relaxation can be solved
by stuff like HIP.

   Erik

---

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

> having a checksum on the source locator causing new failures,

That's a tractable implementation detail.

> and security issues related to relaxing the binding between identifiers

The Security ADs and security-aware IAB folks did not believe that
such issues were real.

> http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-ipngwg-esd- 

And note that a whole lot of folks objected to that being published
as an RFC on grounds that it was analysing something different from
what O'Dell proposed and also because there were sundry incorrect
assertions (including, but not limited to, security claims) inside it.

> Note that the security issues due to the relaxation can be solved

See smb's comments at www.research.att.com, URL posted by someone else
a few days back.  HIP has no special magic in this regard.

Ran
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Feb 2003 14:11:22 +0100

=> but this draft (draft-ietf-ipngwg-esd-analysis-05.txt) remains
the best introduction to two-space systems... I remember the interim
meeting where GSE/8+8 was not adopted: the main problem was failover.

=> two-space systems are still raisonable long term solutions, especially
HIP (Host Identity Payload Protocol) which doesn't share the security
concern on the binding between the locator and the identity.
(PS: and its overhead is not a problem for guys like me who'd like
to hide everything behind ESP :-).

Thanks

[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 22 Feb 2003 15:19:14 +0100 (CET)

> to hide everything behind ESP :-).

Is there a good write-up of HIP yet?

We should really watch the overhead, because most of the time it's
simply unnecessary. Want do do voice over IP with IPsec? If you don't do
the IPsec in the phone, you MUST use tunnel mode as per the RFC. But you
can't do routing over IPsec tunnels, so you need another GRE tunnel.
Then comes the ESP overhead, which is actually fairly small but they
chose to inlcude padding, which IMO was a mistake. Also, the
initialization vectors eat up a fair number of bytes, while it wouldn't
be very hard to come up with a scheme where the IV isn't carried inside
the packet. Then of course we encapsulate all of this in an ethernet
frame which wastes 64 bits on a preamble and 160 bits on an inter frame
gap, which are necessary to make the manchester encoding work. Since we
typically use ethernet with encodings that regulate this stuff at even
lower layers, most of these 20 bytes are wasted for no reason.

So in order to carry a 64 kbps voice stream in more or less 64 kbps and
have a reasonable delay, we need to compress the actual payload by a
factor 4 to make room for the overhead, which is then 78%. About half of
this could be removed without any impact to functionality.

The problem with many headers is that they implement too much. Ideally,
each function would have its own header so you only need to include the
headers you're actually going to use. (IPv6 options have the right
idea.) But of course that leads to header recognition overhead, where
each header needs a header...

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Feb 2003 16:00:24 +0100

=> draft-jokela-hip-packets-xx.txt and old I-Ds by Robert Moskowitz.

   We should really watch the overhead, because most of the time it's
   simply unnecessary. Want do do voice over IP with IPsec? If you don't do
   the IPsec in the phone, you MUST use tunnel mode as per the RFC.

=> HIP is end-to-end.

   But you can't do routing over IPsec tunnels, so you need another
   GRE tunnel.

=> fortunately this is not 100% true.

   the packet.

=> both are properties of the algorithm(s), not of ESP itself.
And security has a price...

   Then of course we encapsulate all of this in an ethernet

=> if they could be removed they could be compressed too.

=> I am afraid we are outside the scope of the MULTI6 list.

Regards

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 22 Feb 2003 16:30:29 +0100 (CET)

> => draft-jokela-hip-packets-xx.txt and old I-Ds by Robert Moskowitz.

Excellent, I'll look them up.

> => fortunately this is not 100% true.

I meant "routing protocols" here.

> => both are properties of the algorithm(s), not of ESP itself.

Yes, padding and IVs are necessary. But that doesn't mean they have to
be carried in the packets. If you use a stream cipher you don't need to
pad. IVs can be generated independently by both ends from pre-shared
information.

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 22 Feb 2003 20:35:52 +0200

> a few days back.  HIP has no special magic in this regard.

HIP has no special magic, I agree.  It just uses public keys
as primary identifiers.  That is pretty similar to what SSH
does today.  HIP has both an opportunistic mode, more or less
similar to the way SSH hosts learn the keys of the other hosts,
and a DNS(sec) based mode where you learn the public key of
the intended recipient form the DNS.  That latter comes, of
course, with the usual problems with DNS(sec) or any other
PKI (like) system.

 From my point of view, the ability to use public keys as
primary identifiers of end-hosts opens up some interesting
ways to deal with some security problems.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 22 Feb 2003 20:44:40 +0200

>>> two-space systems are still raisonable long term solutions, especially
> draft-jokela-hip-packets-xx.txt and old I-Ds by Robert Moskowitz.

We are in the process of revising the drafts; I'm trying
to get two of them out by the next deadline, but I may miss it.
Bob's old drafts contain some small mistakes or ambiguities;
we are trying to fix (most of) them.

In the mean while, our recent paper at NDSS'03 may be
easier to approach.

http://www.tml.hut.fi/~pnr/publications/NDSS03-Nikander-et-al.pdf

There are also slides at http://www.tml.hut.fi/~pnr/presentations/

--Pekka Nikander

---

From: RJ Atkinson <[email-masked]>
Date: Sun, 23 Feb 2003 11:23:56 -0500

On Saturday, Feb 22, 2003, at 09:19 America/Montreal, Iljitsch van 
Beijnum wrote:
> But you can't do routing over IPsec tunnels, so you need another GRE 
> tunnel.

That's untrue.  Nothing prevents one from routing over an IPsec tunnel,
in fact it is quite commonly deployed.  One might choose not to do so,
as a matter of policy, but there is nothing in ESP/AH that prevents
one from doing so.

And I know folks who deployed VoIP/ESP+AH several years ago.  It works
fine -- and the encryption is not implemented inside the phone.

Mind, neither the original posting nor this followup is tremendously
on-topic for this list.

Ran