Subject: [RAM] PASH: Another SHIM6 proxying draft, in addition to pshim6

From: Pekka Nikander <[email-masked]>
Date: Thu, 1 Mar 2007 09:00:17 +0200

Another new draft, http://www.ietf.org/internet-drafts/draft-nikander- 
ram-pash-00.txt , outlines how to proxy SHIM6 in a slightly different  
way than PSHIM6; it also discusses HIP proxying.  It is not as  
detailed as PSHIM6; instead it tries to show that it is indeed  
possible to use SHIM6 (and HIP) in a LISP-like way.  However, it is  
important to remember that SHIM6 and especially HIP provide much more  
than LISP does; see e.g. Markus Stenberg's recent message.

 From a deployment point of view the biggest difference between  
PSHIM6 and PASH seems to be that PASH outlines scenarios that require  
less machinery between the legacy hosts and the network than PSHIM6  
does; PSHIM6 also includes some discussion about that in Section 7.   
The generix draft [1] tries to generalise the different approaches,  
but unfortunately as of today it may be still too scanty to be really  
comprehensible, at least if the reader is not willing to think hard.   
However, I hope that the PASH (and PSHIM6) help to digest the generix  
message.

The more architectural message here is that there indeed seems to be  
pretty independent dimensions of where to implement id/loc split:  
where to implement it vertically (in the stack), and where to  
implement it horizontally (in the host/network).  A third (though not  
independent) dimension is the nature and routability/resolvability of  
identifiers, along the lines of LISP 1, 1.5, 2, and 3 deployment  
scenarios.

--Pekka Nikander

[1] http://www.ietf.org/internet-drafts/draft-nikander-ram-generix- 
proxying-00.txt

On 28 Feb 2007, at 13:45, marcelo bagnulo braun wrote:

> Hi,
>
> i have included in this draft some level of detail on how to do  
> proxies in shim6, in order to support unmodified hosts, allow some  
> middle boxes to perform egress path selection and provide PI  
> identifiers, so that we can have an idea of how this would look  
> like in the shim approach
>
> Comments are welcome
>
> Regards, marcelo
>
> Inicio mensaje reenviado:
>
>> De: [email-masked]
>> Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00
>> Para: [email-masked]
>> Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt
>> Responder a: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> 	Title		: Proxy Shim6 (P-Shim6)
>> 	Author(s)	: M. Bagnulo
>> 	Filename	: draft-bagnulo-pshim6-00.txt
>> 	Pages		: 22
>> 	Date		: 2007-2-27
>> 	
>>    This draft discusses extensions to the shim6 architecture to  
>> support
>>    shim6 proxies that would allow the provision of the following
>>    capabilities:
>>    o  Provide Upper Layer Identifier portability.
>>    o  Provide Traffic Engineering policy enforcement.
>>    o  Off-load of the shim6 context management from the actual  
>> peers of
>>       the communication.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the  
>> body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-bagnulo-pshim6-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[email-masked].
>> In the body type:
>> 	"FILE /internet-drafts/draft-bagnulo-pshim6-00.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <[email-masked]>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
> _______________________________________________
> RAM mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ram
>

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 2 Mar 2007 09:04:45 -0800

> It is not as detailed as PSHIM6; instead it tries to show that it  
> is indeed possible to use SHIM6 (and HIP) in a LISP-like way.

Pekka, I'm going through our IDs, but can you provide me a quick, but  
more specific reply to the above? What is a "LISP-like way" that  
SHIM6 and HIP do not have right now?

It makes it sound that SHIM6 and HIP do not have something that LISP  
does and that you can change them to have it. And what you want them  
to have seems of value to you, so can you identify it?

Thanks,
Dino

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 2 Mar 2007 20:43:17 +0200

> Pekka, I'm going through our IDs, but can you provide me a quick,  
> but more specific reply to the above? What is a "LISP-like way"  
> that SHIM6 and HIP do not have right now?

In a word: deployment.

Your LISP 1, 1.5, 2, 3 construction is nice, as I already wrote.  I  
had been thinking about HIP proxying for years, and about deployment  
along the same lines as you do in LISP, but never managed to put it  
down before now.  Thanks for forcing me to do it. :-)

> It makes it sound that SHIM6 and HIP do not have something that  
> LISP does and that you can change them to have it. And what you  
> want them to have seems of value to you, so can you identify it?

Again: deployment.  I think the LISP deployment path idea is really  
nice, for a starter.

Sorry for being blunt, but other than that I consider LISP very under- 
developed.  As I have stated, once you add security and multi-homing/ 
TE support you probably get something very much like SHIM6, at least  
for the IPv6 EID case.  (You can still run it over IPv4 core.)  As  
far as I can see, security for the IPv4 EID case is a more-or-less  
unsolved problem at this point; I don't think the community would  
even agree on requirements.

So, if I was forced to pick my plate from the currently discussed  
smorgasbord, I would pick the following:

1. A deployment path starting from LISP-like in-the-network  
approaches, gradually going to host-based ones, at least for mobile  
hosts.

2. SHIM6-like mapping set-up and maintenance protocols.

3. SHIM6-like security model with a LISP1.5-like deployment model,  
with IPv6 EID support only and with a separate routing infrastructure  
for locators (IPv4) and identifiers (IPv6).

4. Ability for multiple tunnelling formats (negotiated), including  
SHIM6 tags and IPsec ESP.

5. Forward compatibility with HIP, for LISP 2 and 3 like deployments,  
with ORCHIDs instead of CGAs.

--Pekka Nikander

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 2 Mar 2007 13:18:25 -0800

> Sorry for being blunt, but other than that I consider LISP very  
> under-developed.

Sorry, but that was intended, a feature and not a bug.

>   As I have stated, once you add security and multi-homing/TE  
> support you probably get something very much like SHIM6, at least  
> for the IPv6 EID case.

I don't think so. Some things are meant to be left alone. Multi- 
homing and TE are already there so I don't know what you mean. And  
you can do a lot with less rather than more. Let's have deployment  
tell us what we really need. It's too early to say what we *really*  
need.

Everything needs security, but if you really take a look at the  
Internet under the covers, very little of it (at layer 3) has any  
security. Now why is that?
If it was such a serious problem, don't you think it would have been  
deployed by now?

> approaches, gradually going to host-based ones, at least for mobile  

Okay, makes sense.

> 2. SHIM6-like mapping set-up and maintenance protocols.

Sorry, way too complicated for my tastes. And I'm not alone here.

> with IPv6 EID support only and with a separate routing  
> infrastructure for locators (IPv4) and identifiers (IPv6).

Tell me specifically what SHIM6-like security model you are talking  
about.

> SHIM6 tags and IPsec ESP.

Why do we need this? How about just ESP (or maybe just AH).

> 5. Forward compatibility with HIP, for LISP 2 and 3 like  
> deployments, with ORCHIDs instead of CGAs.

Right, pretty grandiose IMO. It sounds like you are compromising and  
taking a little from everywhere. In my experience, this is a recipe  
for disaster.

Dino

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 3 Mar 2007 08:29:27 +0200

> Sorry, but that was intended, a feature and not a bug.

Ok, but it makes comparison with something more fully developed, such  
as the SHIM6 *protocol*, pretty hard. That is, you get very YMMV  
statements due to comparing apples to oranges.  Consider your own  
comment later:  You simultaneously say that SHIM6 is too complicated  
and LISP is intentionally under-developed.  Then you go saying that  
you don't believe LISP will become comparably complex with SHIM6 when  
fully developed while I believe so.

Well, what can I say?  Maybe you have some clever idea in mind that I  
cannot see.  Or maybe you don't yet understand all the complications  
involved.  Or maybe we just don't agree on what is needed, e.g.,  
security wise.

> homing and TE are already there so I don't know what you mean.

Well, I think I disagree.  Maybe I'm wrong about multi-homing or TE,  
but I think my security point prevails.  :-)

> And you can do a lot with less rather than more. Let's have  
> deployment tell us what we really need. It's too early to say what  
> we *really* need.

There I fully agree.  But, my approach would be somewhat opposite to  
yours: instead of starting from zero and building the minimum needed,  
I'd start from something pretty fully developed and tested (such as  
SHIM6 or HIP), and remove features that are not needed for early  
deployment.

The benefit?  Forward compatibility, i.e., more-or-less technically- 
proven way of adding back those removed features further along the  
deployment path.  (But I also know that technical forward  
compatibility does not necessarily mean forward compatibility  
deployment wise.  It just makes such forward compatibility  
*potentially* much easier.)

> If it was such a serious problem, don't you think it would have  
> been deployed by now?

As I wrote, I think the community does not agree on the  
"requirements" here, or how bad the problem is.

For me, anything that allows *new* reflection, amplification, or  
flooding attacks is unacceptable.  The situation is bad enough  
already now.  Any new attack vector can prove to be more effective  
than the old ones.   But I know people who disagree with me.

[Snipping my smorgasbord plate.]

> Right, pretty grandiose IMO. It sounds like you are compromising  
> and taking a little from everywhere. In my experience, this is a  
> recipe for disaster.

Point taken.

But you forget I'm a pragmatist.  I'm willing to give up any nice  
features that are not necessary (e.g. security wise) and turn out to  
be complicated to implement.  Of course, I happen to believe that my  
choice would be quite palatable, but obviously it can turn out to be  
very sour or just too much to swallow, when worked out.

--Pekka Nikander

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 3 Mar 2007 12:15:31 +0100

Hi,

El 02/03/2007, a las 22:18, Dino Farinacci escribió:

>
>>   As I have stated, once you add security and multi-homing/TE support 
>> you probably get something very much like SHIM6, at least for the 
>> IPv6 EID case.
>
> I don't think so. Some things are meant to be left alone. Multi-homing 
> and TE are already there so I don't know what you mean.
>

Well, w.r.t. to multihoming, i think that one preferred feature in 
multihoming is fault tolerance. AFAICT, in the current version of LISP, 
the ITR is a single point of failure (see the message i sent about this 
in http://www1.ietf.org/mail-archive/web/ram/current/msg00636.html)
So, i don't think it is acceptable to have a multihoming solution which 
goal is to provide fault tolerance and that it introduces a single 
point of failure in a router. OTOH, i only have read LISP once, so i 
may be missing some points, hence my previous question. I think that 
quite some additional compelxity is needed to support to fall back to a 
backup ITR and preserve established sessions in the cases that i have 
described before.

w.r.t. to TE, AFIU, LISP uses multiple tunneling level in order to 
allow that some internediate router can reroute the packets. But in 
order to do that, the intermediate router needs to discover the 
alternative locators for the identifier contained in the packet and 
moreover, it needs to know that the destiantion site is LISP aware 
(which is not trivial in LISPv1, since the identifier is routable, so a 
lisp packet can be a regular IP packet)

So, in order to discover the alternative locators associated to the 
identifier, the intermediate rotuers needs to keep track of the ICMP 
mesages (is this the idea?). So this means that intermediate routers 
need to store all the alternative locators for packets flowing through 
it? What if the locator used is not the one used initially and the ICMP 
packet didn't passed through that router initially? in this case, how 
does the intermediate router discover the alternative locators? In 
addition to that, you need to consider the security aspect. I mean, in 
this case you need to provide security for the id locator binding to 
some unspecified router in the middle. Again, i am not saying that this 
cannot be done, just that additional complexity will be needed for sure 
even to provide support for multihoming and TE

but again, i still have a poor understanding of LISP, so i am probably 
missing some stuff here...

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 4 Mar 2007 17:20:46 +0100

> Comments are welcome

You say something to the effect that shim6 makes it hard to enforce TE.

I would like to object to the notion that anyone GETS to "enforce"  
TE. If a host or user has internet access service, this means it, he  
or she gets to send and receive a certain amount of traffic per unit  
of time. Some light-weight influencing of this by ISPs can be  
beneficial to both the ISP and the user, but fundamentally, the user  
pays so the ISP is obligated to carry the traffic: no enforcing.  
Further, if the host is single homed the ISP doesn't get to do any  
traffic engineering either.

Good writeup, but nothing surprising, as you say, most of this stuff  
has been talked about in shim6 circles before. The main problem that  
I see is deployment: it just needs too many little and not so little  
things to be changed in order to work.

Nits:

"globally routing addresses": this sounds strange and is also not  
100% clear.

Who is "we"? Didn't you write this alone?  :-)

You spelled my name wrong in the references section.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 4 Mar 2007 17:55:09 +0100

Hi Iljitsch,

thanks for the feedback

El 04/03/2007, a las 17:20, Iljitsch van Beijnum escribió:

>> identifiers, so that we can have an idea of how this would look like 
>> in the shim approach
>
>> Comments are welcome
>

What i wanted to say is that if for some reason (e.g. backward 
compatibility with non-shim6 capable hosts) multiple routable addresses 
are presented to the host within the multihomed site and it is up to 
the host to select the source address among them, then it can override 
the TE policies of the site and then the network admin of the site 
cannot enforce TE, since the host can override the router decisions.

However, if the hosts within the multihomed site are configured with 
only one non globally routable ID, and it is only up to the P-shim to 
select the locators to be used, then the one configuring the P-shim box 
is the one that is defining the TE and also enforcing it.

> I would like to object to the notion that anyone GETS to "enforce" TE. 
> If a host or user has internet access service, this means it, he or 
> she gets to send and receive a certain amount of traffic per unit of 
> time. Some light-weight influencing of this by ISPs can be beneficial 
> to both the ISP and the user, but fundamentally, the user pays so the 
> ISP is obligated to carry the traffic: no enforcing. Further, if the 
> host is single homed the ISP doesn't get to do any traffic engineering 
> either.
>
> has been talked about in shim6 circles before. The main problem that I 
> see is deployment: it just needs too many little and not so little 

you may be right

>
> Nits:
>
> "globally routing addresses": this sounds strange and is also not 100% 
> clear.
>

should read globally routable address

> Who is "we"? Didn't you write this alone?  :-)

:-)

it is my literary style and/or my schizophrenic personality

> You spelled my name wrong in the references section.

i am sorry about that... i should have learned it by now...

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 4 Mar 2007 17:55:09 +0100

Hi Iljitsch,

thanks for the feedback

you may be right

:-)

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Mar 2007 17:08:14 +0100

I have a couple of questions about pash.

pshim6 finds a need for a DNS ALG. Does pash have the same need?

How will pash deal with TCP relays along the path (which
recompute the TCP checksum)? This is an open issue for shim6
and pshim6.

     Brian

---

From: Geoff Huston <[email-masked]>
Date: Tue, 06 Mar 2007 09:16:01 +1100

>recompute the TCP checksum)? This is an open issue for shim6

At some point the extended legacy of a small number of demented 
pieces of middleware simply has to stop. Any intermediary system 
performing TCP and UDP checksums  on packets on the fly is simply 
generating heat rather then an  enlightened state of blissful 
protection! Adjusting generic end-to-end behaviours for such deranged 
middleware is, imho, a collective waste of time.

So, no I don't see this was an open issue for shim6.

Geoff

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 6 Mar 2007 07:47:35 +0200

> pshim6 finds a need for a DNS ALG. Does pash have the same need?

That depends on the deployment scenario.

I also talked about this with Marcelo last week, and our conclusion  
was that if you modify pshim6 to use existing PA addresses instead of  
new PI space as the identifiers, you can also do shim6 without DNS  
ALG some other odds and ends.  There might also be scenarios where  
you use some kind of "half-PI" addresses as identifiers, but more  
work is needed in that space.  Marcelo prepared some additional text  
to pshim6 but I don't know if he managed to post it before  
yesterday's deadline.

More generally, I started analysis of this problem (independent of  
pshim6) in the generix draft.  There  are some text in Sections 6.3  
and 6.4.  That is not much, but perhaps a beginning.

> How will pash deal with TCP relays along the path (which recompute  
> the TCP checksum)? This is an open issue for shim6 and pshim6.

That depends on a level of detail to which PASH doesn't directly go  
(nor does LISP, IIRC).

In addition to SHIM6 proxying, PASH also outlines HIP proxying.  In  
the HIP case, you have ESP, and the problem goes away since TCP  
relays won't see the TCP checksum.  Or, if they do see it, due to ESP  
NULL encryption, they should recognise the ESP header and not touch  
the TCP header.

For SHIM6 proxying, I don't think PASH is any different from PSHIM6  
in this respect.  PASH just outlines a number of deployment  
scenarios, each requiring slightly different details, while PSHIM6  
focuses only one.

So, my tentative conclusion here is that the need for DNS ALG and  
other such details depends more on the deployment scenario, i.e., the  
nature of identifiers used, than the underlying id/loc separation  
mechanism.  So, the question is more if we use XXXX 1, 1.5, 2, 3  
rather than if XXXX is LISP, PASH, or something else.

I'll try to add some text about this to a future version of the ILSE  
draft.

--Pekka Nikander

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 6 Mar 2007 12:47:57 +0100

> rather than if XXXX is LISP, PASH, or something else.

exactly

If you you want a scenario where:

The nodes within the multihomed site only configure a single address 
that is provider independent.
We assume that the provider independent address that is configured in 
the node cannot be globally routable (since this would bloat the 
routing tables and so on)
This basically imposes the following constraints
- If we are considering a situation where a host A in a multihomed site 
using PI identifiers wants to communicate with another host B in a 
different multihomed site that is using PI identifiers, then The PI 
identifier of host B must be returned to host A in a AAAA RR since host 
A only understand AAAA RR.
- If we are considering a legacy host C that is not server by a proxy 
or LISP router that wants to  initiate a communication with host A, 
then the DNS must returns a routable address of host A in the AAAA RR 
to host C

So the result is that the information returned by the DNS in AAAA RR 
for hosts behind a Proxy or LISP router (in the 1,5 2 and 3 cases) 
should be the PI identifier for other hosts behind a proxy and a 
routable address for legacy hosts not behind a proxy

The solution for this seems to require some form of DNS ALG as long as 
hosts don't support a new EID RR AFAICT

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2007 15:49:10 +0100

On 2007-03-05 23:16, Geoff Huston wrote:
> At some point the extended legacy of a small number of demented pieces 
> of middleware simply has to stop. Any intermediary system performing TCP 
> and UDP checksums  on packets on the fly is simply generating heat 
> rather then an  enlightened state of blissful protection! Adjusting 
> generic end-to-end behaviours for such deranged middleware is, imho, a 
> collective waste of time.
> 

I'm actually quite happy with the middlebox text Marcelo has
proposed in shim6. We can't pretend that silly middleboxes don't
exist, but let's at least document what they need to do or not do.

    Brian