Subject: Re: filters and ACLs on identifiers? (was Re: other requirement? (was Re: [RAM] Traffic Engineering

From: [email-masked] (Noel Chiappa)
Date: Mon, 1 Jan 2007 17:22:47 -0500 (EST)

> From: marcelo bagnulo braun <[email-masked]>

    > you cannot make filers and ACL based on identifiers unless you can
    > trust them. In the case of routing names, you can have some level of
    > trust, because, if you trust the routing system, then you know this
    > packet will only be delivered to the destiantion locator.

But you can't really trust the source locator, of course; all it takes is a
few sites which don't do source-address filtering, and bogons can appear at
any given destination. So you can't reliably filter anything you are basing
in part on the source locator.

    > However, you do not have this level of trust if you use identifiers and
    > you need to provide additional mechanism (that result in additional
    > overhead or state) to achieve it

Hmm. Well, that's a point worth thinking about.

I think you probably can trust the destination ID, because if that
destination is really at the place the packet got to, and the packet is
delivered to that destination, it will presumably recognize that the packet
is not for it, and reject it. And of course, as discussed above, you can't
really trust source addresses now. So, it's not clear to me that we are any
worse off than we are now.

Am I missing something?

	Noel

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

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 1 Jan 2007 14:29:13 -0800

On Jan 1, 2007, at 2:22 PM, Noel Chiappa wrote:

> is not for it, and reject it.

One consideration in this general area is reflection attacks; I know  
they don't bear directly upon what's being discussed, but it's  
arguable that they represent one class of traffic in which the  
*ultimate* desired destination for packets is 'spoofed', too, as it  
were.

Another consideration would be a scenario in which an attacker knows  
(or could reasonably infer) that there is some mechanism which will  
end up redirecting packets ostensibly destined for A over to B and/or  
C.  Again, this is probably not germane to the discussion, but I  
point it out for the sake of completeness.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

		All battles are perpetual.

     		   -- Milton Friedman

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Jan 2007 17:46:41 +0100

> in part on the source locator.

agree,

> destination is really at the place the packet got to,

i am not sure...

the packet really goes to the destiantion _locator_ not to the 
destiantion identifier.So you can trust the destiantion locator, but if 
you carry in the packet both the destiantion locator and the 
destiantion identifier, you can only trust the destiantion locator and 
not the destiantion identifier.

>  and the packet is

i am not sure what attacks are we considering, but including a 
destiantion identifier that is accepted by the ACLs and including a 
destiantion locator of another machine, is a simple way to bypass the 
ACL and being able to send packets towards a machine that the ACL 
doesn't want you to. Not sure if this is a relevant attack though...

Regards, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Jan 2007 16:32:42 +0200 (EET)

> in part on the source locator.

The situation is not necessarily quite that bad.  For connections that 
both originate and terminate inside a trusted part of the network, 
source IP address filtering can be rather reliable.  See section 1.2 
of draft-savola-rtgwg-backbone-attacks-02.txt.

For example, if an ISP implements ingress filtering at all of its 
borders, and an access list only allows access from a couple of 
management LANs inside that ISP's network, if someone in the Internet 
spoofs source addresses of the LAN destined to the ISP, they will be 
dropped at the border.

This is one weakness of GSE-like solutions (a minor variation of this 
exists in SHIM6 as well): you may not be able to effectively drop 
packets which spoof your host identities at the border of your 
{site,other trust border}.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings