Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00

From: "Bound, Jim" <[email-masked]>
Date: Fri, 2 Mar 2007 00:08:59 -0500

LISP solution if accepted removes the need to do split ID/LOC for now.
Also in my view watching this mail none have answered Brian Carpenters
mail on the issues of LOC/ID split and the trade-offs from some time
ago.  That reinforces for me true split of LOC/ID is really an IRTF
effort not an IETF effort and will take a minimum of 5 years.  What LISP
does is provides an opportunity to view a short term solution to the RAM
issues identified within LISP. I for one am not worried about the
encapsulation at ITR to ETR and decap at ETR.  Additional security can
be specified and defense in depth with IPsec VPNs is achievable over a
routed network path.  Also as LISP states this does not preclude
continued work on SHIM6, which I still think is important to move
forward.

/jim 

> -----Original Message-----
> From: Henderson, Thomas R [mailto:[email-masked]] 
> Sent: Monday, February 26, 2007 6:27 PM
> To: Dino Farinacci
> Cc: [email-masked]
> Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00
> 
>  
> 
> > -----Original Message-----
> > From: Dino Farinacci [mailto:[email-masked]]
> > Sent: Monday, February 26, 2007 2:03 PM
> > To: Henderson, Thomas R
> > Cc: Brian E Carpenter; [email-masked]
> > Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00
> > 
> > > I agree with Brian's complaint here; LISP is really about 
> multiple 
> > > levels of locators and not really an ID/locator split, based on 
> > > traditional use of these terms.
> > 
> > LISP is both, just like GSE is.
> > 
> 
> It's not equivalent to GSE, which actually split the IP 
> address into ID and locator portions.  LISP is an ID/locator 
> separation (the draft title uses the word separation, but 
> also uses the word "split" internally) only in the context of 
> a particular address allocation and routing policy.  Again, 
> this is just terminology, but I think it would be more 
> precise to define it in terms of multiple locator spaces that 
> are tunneled over one another, for purposes of core routing 
> scalability.
> 
> Tom
> 
> _______________________________________________
> 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: Pekka Nikander <[email-masked]>
Date: Fri, 2 Mar 2007 10:32:51 +0200

Jim,

A few quick comments:

1. Personally, I believe that we can do with SHIM6 (or HIP) what LISP  
aims to do either as easily, or at least almost as easily, as a fully  
developed version of LISP would do.  We try to outline that in the  
PASH draft,

http://www.ietf.org/internet-drafts/draft-nikander-ram-pash-00.txt

2. I started to analyse the design space related to id/loc split.   
However, given the time limits I didn't get that far, yet.  The  
current version, mostly bare bones, is the ILSE draft:

http://www.ietf.org/internet-drafts/draft-nikander-ram-ilse-00.txt

Based on my/our argumentation therein, my tentative conclusions are  
the following:

We should go for a full-blown but simplified id/loc split, probably  
based on SHIM6.  We could start by simplifying SHIM6 quite a lot,  
e.g. by forgetting e.g. even SHIM6 multi-homing features, but still  
use the protocol and security framework, for *forward*  
compatibility.  As far as I can see, running over IPv4 should not be  
a problem here; using IPv4-address-like identifiers may be a real  
challenge, but might be solvable for very early deployment, depending  
on your trust model.

Starting from LISP, you could get there by a) using the SHIM6  
protocol instead of ICMP, b) using SHIM6 tags instead of tunnelling  
(but this is not important), c) using CGAS as identifiers, and d)  
adopting the LISP 1.5 deployment approach, basically meaning separate  
routing infrastructures for IPv4 (locators) and IPv6 (identifiers).   
But I don't know if that was the best way, or even a good one.

Alternatively, you could start from PASH or PSHIM6, and end up at  
pretty much the same target.

Replacing the IPv6 routing infra with a DHT or similar would allow  
you to use ORCHIDs too, enabling HIP as a (forward compatible) option.

Trying to crystallise my standing:  Removing the need for id/loc  
split for now would be a BAD thing for the Internet.  Read Mark  
Handley's "Why the Internet just works."  If we remove the energy  
that the community now has through yet another ugly pat^H^H^H^H^H  
point solution, I doubt we will ever get another chance to implement  
the id/loc split.

But then, losing the current opportunity might be a good thing for  
the clean slate approaches. :-)

--Pekka Nikander

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 19 Mar 2007 02:06:13 -0400

Pekka N.,

I have read the below and updates to the respective drafts.  I am still
convinced we need to treat split loc/id as IRTF work and emerging
technology. LISP is the direction we should follow to address RAWs
problem space.  In general across the IETF I support very limited and
judicious use of middle boxes that are not router type nodes.  

Note 1 - your solution at the edge will not work if two P2P clients on
either end encrypt packet with IPsec only exposing the IP header (and
with IPv6 some options).  LISP will still work and one of my original
questions to authors of LISP.  LISP does not break E2E or transparency
as the proxy approach will and a proxy for the RAWs solution causes
additional network security problems as all proxies do today on the
Internet.  I do not consider LISP a proxy before others go there as a
note too, but a routing function that is valid.

Note 2 - the issues of attacks from RFC 4218 and the IP header are valid
but the answer cannot be an IETF solution that unacceptable IPR claims
from an Internet market business view for such a potential IETF spec
solution that could exist on every node on the provincial Internet.
Also I believe industry will address most of these out of IETF band
solutions using IDS and IDP.  Also LISP is transparent to the use of
securing IP addresses and this is separate discussion.

Note 3: I do believe your work on this is important research for the
Internet community at large.

Best,
/jim

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Friday, March 02, 2007 3:33 AM
> To: Bound, Jim
> Cc: Thomas R Henderson; Dino Farinacci; [email-masked]
> 1. Personally, I believe that we can do with SHIM6 (or HIP) 
> what LISP aims to do either as easily, or at least almost as 
> easily, as a fully developed version of LISP would do.  We 
> try to outline that in the PASH draft,
> 
> However, given the time limits I didn't get that far, yet.  
> The current version, mostly bare bones, is the ILSE draft:
> 
> Based on my/our argumentation therein, my tentative 
> conclusions are the following:
> 
> We should go for a full-blown but simplified id/loc split, 
> probably based on SHIM6.  We could start by simplifying SHIM6 
> quite a lot, e.g. by forgetting e.g. even SHIM6 multi-homing 
> features, but still use the protocol and security framework, 
> for *forward* compatibility.  As far as I can see, running 
> over IPv4 should not be a problem here; using 
> IPv4-address-like identifiers may be a real challenge, but 
> might be solvable for very early deployment, depending on 
> your trust model.
> 
> protocol instead of ICMP, b) using SHIM6 tags instead of 
> tunnelling (but this is not important), c) using CGAS as 
> identifiers, and d) adopting the LISP 1.5 deployment 
> approach, basically meaning separate  
> Alternatively, you could start from PASH or PSHIM6, and end 
> up at pretty much the same target.
> 
> Replacing the IPv6 routing infra with a DHT or similar would 
> allow you to use ORCHIDs too, enabling HIP as a (forward 
> compatible) option.
> 
> 
> Trying to crystallise my standing:  Removing the need for 
> id/loc split for now would be a BAD thing for the Internet.  
> Read Mark Handley's "Why the Internet just works."  If we 
> remove the energy that the community now has through yet 
> another ugly pat^H^H^H^H^H point solution, I doubt we will 
> ever get another chance to implement the id/loc split.
> 
> But then, losing the current opportunity might be a good 
> thing for the clean slate approaches. :-)
> 
> --Pekka Nikander
> 
> > effort not an IETF effort and will take a minimum of 5 years.  What 
> > LISP does is provides an opportunity to view a short term 
> solution to 
> > the RAM issues identified within LISP. I for one am not 
> worried about 
> > the encapsulation at ITR to ETR and decap at ETR.  
> Additional security 
> > can be specified and defense in depth with IPsec VPNs is achievable 
> > over a routed network path.  Also as LISP states this does not 
> > preclude continued work on SHIM6, which I still think is 
> important to 
> > move forward.
> 
>

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 19 Mar 2007 09:15:39 +0200

Jim,

Thanks for reading the drafts and thinking about the situation.

A few quick comments:

> I have read the below and updates to the respective drafts.  I am  
> still convinced we need to treat split loc/id as IRTF work and  
> emerging technology. LISP is the direction we should follow to  
> address RAWs problem space.

You may well be right that not going for id/loc split but doing  
something like LISP (or rather eFIT, draft-wang-ietf-efit-00.txt) may  
be a better way to address the immediate RAWs problem space.

OTOH, I think some rudimentary sort of id/loc split would be soon  
ready for wide deployment, if people decide to take the effort.  That  
is, we are not quite there yet, but not that far either, IMHO.

A large open question, IMHO, is whether we should aim for BOTH  
separating core routing from the edge addresses (a la eFit) AND the  
edge addresses from host identifiers, or aim for a combined  
approach.  That'll be main my point on my very brief INT area  
presentation on Thursday.

 From an architectural point of view, I imagine a pattern emerging  
here: more layers.  Perhaps something along the lines Joe Touch et al  
propose in their RNA (Recursive Network Architecture).

> In general across the IETF I support very limited and judicious use  
> of middle boxes that are not router type nodes.

I do not understand that comment of yours.  I don't see any way to  
effectively fight DDoS (within the bounds of the current  
architecture) but add more intelligent middle boxes.  If you still  
want to call them routers is just a matter of terminology.

> with IPv6 some options).

I don't think so.  IIRC, SHIM6 works below IPsec.  Hence, it does not  
make any difference if the address rewriting is done at the host or a  
proxy.  Besides, the tag extension header is not an important detail  
of SHIM6, IMHO.  It could be replaced with tunnelling, at the expense  
of some header growth.

> LISP does not break E2E or transparency as the proxy approach will  
> and a proxy for the RAWs solution causes additional network  
> security problems as all proxies do today on the Internet.

I think you have gotten the issue wrong here, especially what comes  
to security.  Security here does not depend so much whether you call  
the tunnelling/rewriting boxes as proxies or tunnel routers.  It  
depends on your trust assumptions, identifier design, support  
infrastructure, and placement of the boxies.  Writing my view of this  
to the ILSE draft is on my todo list, but unfortunately I'm far from  
it at this point of time.

--Pekka

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Mar 2007 01:18:42 -0700

> questions to authors of LISP.  LISP does not break E2E or transparency

Agree, and as Noel has mentioned, LISP is a "jack-up" scheme meaning  
everything that runs "on top of the jack" doesn't know they are  
jacked-up.

So you can jack-up with a short-term solution and either "jack-up  
again" with a possible long-term solution or replace the short-term  
with long-term with one jack.

Dino

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 19 Mar 2007 05:38:19 -0400

Hello Pekka N.,

Responses where I clarify further below. 

> > emerging technology. LISP is the direction we should follow 
> to address 
> > RAWs problem space.
> 
> You may well be right that not going for id/loc split but 
> doing something like LISP (or rather eFIT, 
> draft-wang-ietf-efit-00.txt) may be a better way to address 
> the immediate RAWs problem space.

I believe eFIT has synergy with LISP and the idea of DHTs is something
that LISP 3 stated as possible goal, and I believe is better approach
than DNS.  Again I am supporting addressing the immediate need with
model that will permit transition to new models which include evolution
to loc/id split if the industry will move in that direction.

> > In general across the IETF I support very limited and 
> judicious use of 
> > middle boxes that are not router type nodes.
> 
> I do not understand that comment of yours.  I don't see any 
> way to effectively fight DDoS (within the bounds of the current
> architecture) but add more intelligent middle boxes.  If you 
> still want to call them routers is just a matter of terminology.

Note I was careful above I said "judicious" use of them not to never use
them.

> I don't think so.  IIRC, SHIM6 works below IPsec.  Hence, it 
> does not make any difference if the address rewriting is done 
> at the host or a proxy.  Besides, the tag extension header is 
> not an important detail of SHIM6, IMHO.  It could be replaced 
> with tunnelling, at the expense of some header growth.

The use of tag as tunnel would work I think need to think about that
one. As I read your proxy I gleaned you had to look at TCP, I will
recheck that read on my part.  My point is any solution can only assume
the IP header and with IPv6 options in front of the IPsec payload.

> 
> > LISP does not break E2E or transparency as the proxy 
> approach will and 
> > a proxy for the RAWs solution causes additional network security 
> > problems as all proxies do today on the Internet.
> 
> I think you have gotten the issue wrong here, especially what 
> comes to security.  Security here does not depend so much 
> whether you call the tunnelling/rewriting boxes as proxies or 
> tunnel routers.  It depends on your trust assumptions, 
> identifier design, support infrastructure, and placement of 
> the boxies.  Writing my view of this to the ILSE draft is on 
> my todo list, but unfortunately I'm far from it at this point of time.

I don't think my view is wrong but my view of work to do first may be
different than yours.  I believe if we can reduce the pain in DFZ and
for multihoming with initial edge solution much of RAWs problem space
can be addressed at least initially.

I think we need to view the network security problems (data in motion)
to find multiple potential answers.

Thanks for your hard work on all those specs it is a lot of work and
appreciated by me in the IETF.

/jim

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Mar 2007 12:03:16 +0100

Pekka, Jim,
> edge addresses from host identifiers, or aim for a combined approach. 
> That'll be main my point on my very brief INT area presentation on
> Thursday.

Yes, this is one of the big questions I would like to get an answer to.
FWIW, I think there's something to be said for a modularization and
making focused solutions to specific problems. But if we do that
then we need to be very clear that it is indeed a solution for a
very specific problem, not the grand tool to get rid of all the pain
caused by the dual role of addresses. OTOH, some of the drafts
seem to say that a more complete solution would also be possible.
If that can be done without unreasonable difficulties, it should
of course be preferred. I don't have a good sense yet on how
easy or hard that would be. I'm hoping Pekka's presentation
on Thursday will provide some light on that.

Jari

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 19 Mar 2007 12:09:40 -0400

Well I cannot imagine any presentation that will move us forward as LISP
is trying too.  The bottom line is there is no way to do loc/id split
with current software/hardware implementations that can be deployed in
less than 5 years, the LISP proposal and prototyping already being
discussed with some implementers here, myself included, could give us
that solution in 2 years with initial deployment at the edges.  I see no
alternative but baby steps towards a solution to RAWs report.  I have
still not seen a good answer to Brian Carpenter's questions on the use
and requirement for split loc/id that would not be an IRTF effort.  The
entire notion is up for debate regarding split id/loc in my view.  

Are we also having a presentation the supports the LISP proposal in
addition to Pekka N's clear biased view (this is not a negative comment
just a fact).

/jim

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 7:03 AM
> To: Pekka Nikander
> Cc: Bound, Jim; [email-masked]
> approach.
> FWIW, I think there's something to be said for a 
> modularization and making focused solutions to specific 
> problems. But if we do that then we need to be very clear 
> that it is indeed a solution for a very specific problem, not 
> the grand tool to get rid of all the pain caused by the dual 
> role of addresses. OTOH, some of the drafts seem to say that 
> a more complete solution would also be possible.
> If that can be done without unreasonable difficulties, it 
> should of course be preferred. I don't have a good sense yet 
> on how easy or hard that would be. I'm hoping Pekka's 
> presentation on Thursday will provide some light on that.
> 
> Jari
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Mar 2007 17:23:08 +0100

Dave Ward will be talking about requirements from a routing
system / deployment point of view, and I believe this is largely
going to be based on Dino's material. And this in turn, was
the rationale behind LISP.

I am very much in agreement with you that we need a deployable
scheme.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Mar 2007 17:23:08 +0100

Jari

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 19 Mar 2007 14:03:55 -0400

thank you Jari appreciate you staying on top of this list with all your
other jobs in the IETF.
/jim 

> Sent: Monday, March 19, 2007 12:23 PM
> To: Bound, Jim
> Cc: Pekka Nikander; [email-masked]
> system / deployment point of view, and I believe this is 
> largely going to be based on Dino's material. And this in 
> turn, was the rationale behind LISP.
> 
> I am very much in agreement with you that we need a deployable scheme.
> 
> Jari
> 
>