Subject: Re: [rrg] Remote ACLs [Proposals which match rrg architectures.html pls check the page]

From: [email-masked] (Noel Chiappa)
Date: Sun, 4 Jan 2009 15:20:55 -0500 (EST)

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

    > Isn't this in fact a (perceived) problem with the multi-prefix model?
    > If an endpoint has multiple locators, then any site that puts one of
    > those locators in an ACL needs to put all of them in the ACL.

Why are people putting locators in ACLs anyway?

(Note: This is not the same thing as the question 'why is the hardware
looking at locators to implement ACLs?'. Looking at locators might be a fine
engineering choice for the _implementation_ of ACLs.)

	Noel
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 4 Jan 2009 13:58:37 -0800

The simple/short answer is because they are being used as IDs.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Sun, 4 Jan 2009 15:50:45 -0800

|The simple/short answer is because they are being used as IDs.

And this is an architectural bug that we should endeavour to fix, not
propagate.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 05 Jan 2009 09:10:51 +0800

> And this is an architectural bug that we should endeavour to 
> fix, not propagate.
 
If we want to use ID in the ACL, should it also have some structure in
semantics? since the flat ID will cause a scaling issue with ACL and a huge
burden for manually configuration.

Xiaohu

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 4 Jan 2009 17:19:07 -0800

If EID-prefixes are allocated from RIRs, we can have structure. That  
is what the LISP architecture defines. Since it's a different  
namespace from the RLOC namespace, it's aggregation boundaries (in the  
address itself) can be different.

Dino

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 05 Jan 2009 12:05:24 +0100

> Why are people putting locators in ACLs anyway?

I guess that one of the problems with using identifier is how can you 
trust the idnetifiers in the packet?
I mean, if you include botht eh ID and the locator in the packet e.g. a 
tunnel, the source locator has some inherent security features, since 
it is the token that will be used by the routing system to send packets 
back, so spoofing it will result in retrun packet going somewhere else.
The identifier does not have such property and spoofing it is trivial.
I guess that if we want to use identifiers in the ACL and make them 
minimally useful, the device holding the ACL needs to verify the ID loc 
mapping, which seems somehow more complex than current practice.

Regards, marcelo

-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Jan 2009 08:53:55 -0800

Dino,

On Jan 4, 2009, at 5:19 PM, Dino Farinacci wrote:
> If EID-prefixes are allocated from RIRs, we can have structure.

Depends on the allocation rules for EIDs, which obviously don't exist  
now.  Right now, the RIRs try to juggle conservation of address space  
with conservation of 'routing slots' with a bias towards the latter,  
resulting in allocations of power-of-2 size blocks aligned on CIDR  
boundaries.  If the RIRs were to allocate EIDs, they would not need to  
be concerned about conservation of 'routing slots', hence non-CIDR  
aligned and non-power-of-2 blocks can be allocated.  If this isn't  
what people want, the RIR public policy process would have to be  
engaged to come up with the EID allocation rules.

Regards,
-drc

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Jan 2009 09:36:55 -0800

So don't you think the decoupling is a good thing? I can see benefits.

Dino

On Jan 5, 2009, at 8:53 AM, David Conrad wrote:

> Depends on the allocation rules for EIDs, which obviously don't  
> exist now.  Right now, the RIRs try to juggle conservation of  
> address space with conservation of 'routing slots' with a bias  
> towards the latter, resulting in allocations of power-of-2 size  
> blocks aligned on CIDR boundaries.  If the RIRs were to allocate  
> EIDs, they would not need to be concerned about conservation of  
> 'routing slots', hence non-CIDR aligned and non-power-of-2 blocks  
> can be allocated.  If this isn't what people want, the RIR public  
> policy process would have to be engaged to come up with the EID  
> allocation rules.
>
> Regards,
> -drc
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Jan 2009 09:41:28 -0800

> I guess that one of the problems with using identifier is how can  
> you trust the idnetifiers in the packet?
> I mean, if you include botht eh ID and the locator in the packet  
> e.g. a tunnel, the source locator has some inherent security  
> features, since it is the token that will be used by the routing  
> system to send packets back,

Don't assume this.

> so spoofing it will result in retrun packet going somewhere else.

You could do a EID-to-RLOC map check at access points (i.e. PE  
routers). That is just a different form or URPF.

> minimally useful, the device holding the ACL needs to verify the ID  
> loc mapping, which seems somehow more complex than current practice.

On the PE box, you may know what customer link has EID-prefixes and do  
the ACL there.

Dino

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Jan 2009 10:05:33 -0800

> So don't you think the decoupling is a good thing? I can see benefits.

Decoupling is good, but it can go farther...

As I hinted at (oh so long ago) during my presentation at the AMS  
workshop, one advantage of indirection-based approaches is that EIDs  
do not need to be allocated hierarchically, thus the existing policy  
constraints for address allocation no longer apply.  The RIRs could  
continue to hand out 'routing slot conservation policy'-constrained  
LOCs since they have the technical expertise to know what this means.   
They could also hand out the EIDs, but since the policy regime for EID  
allocation is fundamentally different than LOCs, it might make sense  
for other bodies (e.g., national allocation entities like NANPA in the  
+1 telephone region) to handle that task.

Of course, if EIDs aren't handed out hierarchically, the existing ACL  
models that rely on locator semantics would obviously break.  Some  
argue this wouldn't necessarily be a bad thing...

Regards,
-drc

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Jan 2009 11:03:24 -0800

> do not need to be allocated hierarchically, thus the

To be clear, do you mean according to network topology hierarchy or  
you mean in power-of-2 blocks? For the later, you want to allocate in  
power-of-2 chunks so your access-lists are kept small. And if the EID  
could encode an AS-number of domain-id that the RIR allocates to the  
site (read: IPv6 allcoations), then we don't have to have the large  
prefix-lists per AS we do today in IPv4.

> existing policy constraints for address allocation no longer apply.   
> The RIRs could continue to hand out 'routing slot conservation  
> policy'-constrained LOCs since they have the technical

Let's not go this route. Let's have service providers allocate RLOCs  
to sites. And just have RIRs allocate EID-prefixes to sites. But RIRs  
would allocate PA RLOC prefixes to service providers.

Make sense?

> expertise to know what this means.  They could also hand out the  
> EIDs, but since the policy regime for EID allocation is  
> fundamentally different than LOCs, it might make sense for other  
> bodies (e.g., national allocation entities like NANPA in the +1  
> telephone region) to handle that task.

By allocating EID-prefixes based solely on address usage, you only  
have a one-dimensional variable.

Let me be clear, I am not disagreeing with anything you are saying,  
I'm just adding more to it. Hope you agree with my statements.

> Of course, if EIDs aren't handed out hierarchically, the existing  
> ACL models that rely on locator semantics would obviously break.   
> Some argue this wouldn't necessarily be a bad thing...

I think a non-starter. We shouldn't let this happen.

Dino

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 06 Jan 2009 10:10:38 +0800

> Let's not go this route. Let's have service providers 
> allocate RLOCs to sites. And just have RIRs allocate 
> EID-prefixes to sites. But RIRs would allocate PA RLOC 
> prefixes to service providers.
> 
> Make sense?

IMHO,  It doesn't matter whether RIRs or NANPA like national allocation
entities allocate EID resources, as long as the allocation is irrelevant to
the service providers, to which the site is connected.

> > expertise to know what this means.  They could also hand 
> out the EIDs, 
> > but since the policy regime for EID allocation is fundamentally 
> > different than LOCs, it might make sense for other bodies (e.g., 
> > national allocation entities like NANPA in the +1 telephone 
> region) to 
> > handle that task.
> 
> By allocating EID-prefixes based solely on address usage, you 
> only have a one-dimensional variable.
> 
> Let me be clear, I am not disagreeing with anything you are 
> saying, I'm just adding more to it. Hope you agree with my statements.
> 

I agree with Dino's opinion. I believe that the flat ID is easy to use for
users but hard to manage for network operators. Freedom (e.g. information
privacy benefits from the flat ID)  sometimes conflicts with Administration,
we should consider some tradeoff between them.

Xiaohu

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Jan 2009 20:33:41 -0800

Dino,

> have a one-dimensional variable.

So, you'd like to overload multiple semantics onto a single namespace  
again?  :-)

Regards,
-drc

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Jan 2009 09:46:27 -0800

> So, you'd like to overload multiple semantics onto a single  
> namespace again?  :-)

No, you have my polarity wrong. I'm saying single dimension is good.

Dino