Subject: Re: [RRG] Renumbering... ACLs etc.

From: Robin Whittle <[email-masked]>
Date: Mon, 18 Aug 2008 02:00:03 +1000

Hi Tony,

You wrote:

> Unfortunately, the practice of putting remote addresses into firewall ACLs
> is all too common.  Of course, there's a name we have for sites that do
> this: pwned.
> 
> That said, this is such a colossaly bad practice, that I would have no
> trouble supporting architectures that forced people to rethink this.

The hardware has to filter packets based on the IP addresses in the
header. It can't very well do some conversion from the IP address to
some FQDN like string of text and do a comparison on that - every
time a packet arrives.

So the router's filter needs an IP address - and perhaps a prefix
length as well.

If you want to be able to instruct the router in some other way than
an IP address, then I guess you would have to use a FQDN or
something else which can be resolved to an IP address by DNS or some
other system outside the router.

That involves several things:

  Firstly, the resolution needs to be done by some robust,
  secure, global mapping system - DNS or something else.

  Secondly, the entity you want to refer to must have an
  entry in that system.

  Thirdly, that system must be updated when the entity to
  be filtered changes its IP address.

  Fourthly, the router needs to find this out ASAP, so it
  can update its IP address.

So I think that in addition to specifying a FQDN or similar, you
would also need to specify a frequency of update - to tell the
router how often it should check with the DNS or whatever to convert
the FQDN or whatever into an IP address.

One problem is that the router could spend a lot of time doing these
DNS lookups, including for things it never in fact sees packets for.
 How many routers are there in a network which need this IP address?
 That could be a lot of DNS activity.

Another problem is that the filtering might not be just on an IP
address, but on the base address of a prefix, and a prefix length.

If that changes, then the global query server system can't just
return an IP address - it needs to return a prefix length too.
Maybe DNS could be updated to do this, or another mapping system
could do the job.

 - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Tony Li" <[email-masked]>
Date: Sun, 17 Aug 2008 11:31:59 -0700

Robin,

I think you're missing the point: having a firewall filter on ANY field set
by a correspondent that cannot be strongly authenticated is simply asking
for trouble.  

To date, folks have claimed that the return routability of the address was
'enough' security.  However, that depends on routing being secure.  I hope
the folks in this group are aware of the reality in that regard.

Tony

|-----Original Message-----
|From: Robin Whittle [mailto:[email-masked]] 
|Sent: Sunday, August 17, 2008 9:00 AM
|To: Routing Research Group
|Cc: [email-masked]
|Subject: Re: [RRG] Renumbering... ACLs etc.
|
|Hi Tony,
|
|You wrote:
|
|> Unfortunately, the practice of putting remote addresses into 
|firewall ACLs
|> is all too common.  Of course, there's a name we have for 
|sites that do
|> this: pwned.
|> 
|> That said, this is such a colossaly bad practice, that I 
|would have no
|> trouble supporting architectures that forced people to rethink this.
|
|The hardware has to filter packets based on the IP addresses in the
|header. It can't very well do some conversion from the IP address to
|some FQDN like string of text and do a comparison on that - every
|time a packet arrives.
|
|So the router's filter needs an IP address - and perhaps a prefix
|length as well.
|
|If you want to be able to instruct the router in some other way than
|an IP address, then I guess you would have to use a FQDN or
|something else which can be resolved to an IP address by DNS or some
|other system outside the router.
|
|That involves several things:
|
|  Firstly, the resolution needs to be done by some robust,
|  secure, global mapping system - DNS or something else.
|
|  Secondly, the entity you want to refer to must have an
|  entry in that system.
|
|  Thirdly, that system must be updated when the entity to
|  be filtered changes its IP address.
|
|  Fourthly, the router needs to find this out ASAP, so it
|  can update its IP address.
|
|So I think that in addition to specifying a FQDN or similar, you
|would also need to specify a frequency of update - to tell the
|router how often it should check with the DNS or whatever to convert
|the FQDN or whatever into an IP address.
|
|One problem is that the router could spend a lot of time doing these
|DNS lookups, including for things it never in fact sees packets for.
| How many routers are there in a network which need this IP address?
| That could be a lot of DNS activity.
|
|Another problem is that the filtering might not be just on an IP
|address, but on the base address of a prefix, and a prefix length.
|
|If that changes, then the global query server system can't just
|return an IP address - it needs to return a prefix length too.
|Maybe DNS could be updated to do this, or another mapping system
|could do the job.
|
|
| - Robin
|
|

---

From: Robin Whittle <[email-masked]>
Date: Mon, 18 Aug 2008 12:02:23 +1000

Hi Tony,

> the folks in this group are aware of the reality in that regard.

OK - I understand that you are suggesting that the routers not
filter by IP address at all, but by "something else".

If that "Something else" is changeable from time-to-time due to
mobility, multihoming service restoration etc. for any one remote
host (or whatever entity it is you are selecting with the filter,
including perhaps an actual person using any host whatsoever) for
which you want to specify the filtering, then I still think the
router needs to periodically look up the text you specified in some
global mapping system to see what this means "now".  In that case,
the text or whatever you use to tell the router how to filter needs
to be accompanied by some information on how often to look up the
mapping system to convert your specification into whatever it needs
to mean to the filtering system right now.

  - Robin

---

From: "Tony Li" <[email-masked]>
Date: Sun, 17 Aug 2008 23:33:18 -0700

Hi Robin,

|OK - I understand that you are suggesting that the routers not
|filter by IP address at all, but by "something else".

Not exactly.  What I'm suggesting is that firewalls cannot reliably filter
on any remote information.  It will be spoofed unless it's strongly
authenticated, such as an IPsec tunnel.

They *can* reasonably filter on local information (e.g., destination IP
address, destination port, protocol, destination identifier, destination
locator).  These are under the control of the local administration and can
conceivably be well coordinated.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Aug 2008 10:27:24 +0200

> filter by IP address at all, but by "something else".

The soon-to-be-classic example of this would be either IPSEC or SSL VPNs 
with IP routed on top.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 Aug 2008 11:30:00 +0200

> the folks in this group are aware of the reality in that regard.

Security is in the eye of the beholder.

The problem with people that have "security" in their job title is  
that they never know when to stop. (Well, it is of course inconvenient  
that every criminal in the world lives less than 300 ms away from your  
valuables.)

In the real world, most buildings have glass windows that are easily  
broken. They provide only a relatively low level of security. (One  
could argue that the only thing that it does is clearly differentiate  
between people who are breaking in and people that aren't.) For most  
people this is good enough most of the time.

Similarly, the return routability check provides enough security for  
most people most of the time.

The fact that a bank needs better security than glass windows doesn't  
mean that glass windows are useless so we can remove them. Also, if  
for some reason we would have to get rid of glass, telling everyone to  
go live in a bank vault isn't the solution. We'd have to come up with  
something that is as inobtrusive as glass and provides at least the  
same level of security, although as long as we're working on it, we'd  
probably want to improve the security level given the same usability  
level.

In other words: in a loc/id solution you lose the return routability  
check on the identifiers so new security mechanisms are needed that  
are at least as strong as the (fairly weak) return routability check.  
These need to be easier to work with and more efficient than IPsec,  
though.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Aug 2008 07:07:53 -0400

I wish I could agree not just with the "should" but with "we can 
persuade them to."  I worked behind an actively managed and supervised 
firewall for a while.  They had a quite strict security policy in place.
Their policy was to block all inbound connections to their VPN device 
unless those connections, and the IP addresses for them, had been 
explicitly authorized.
Yes, they know that IP addresses can be spoofed.  But this sort of 
filtering made the barrier to penetrating the firewall significantly 
higher.  (It meant I could not use the VPN, as they would not authorize 
any dynamic IP addresses.)
Trying to tell them that their policy is wrong, and that they can not do 
that, is not going to work.  We have to provide them something else to 
get the same capability if we do not want them using locators for this.

Yours,
Joel

PS: The one we ought to be able to persuade folks to fix is the "trick" 
of tying software licenses to server IP addresses.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Aug 2008 16:36:47 +0200

Joel,
> higher.  (It meant I could not use the VPN, as they would not 
> authorize any dynamic IP addresses.)
> Trying to tell them that their policy is wrong, and that they can not 
> do that, is not going to work.  We have to provide them something else 
> to get the same capability if we do not want them using locators for 
> this.

What you point out is that it is necessary but not sufficient to secure 
the so-called "identifier" space.  We are not excused from securing the 
locator space.

Eliot

---

From: "Tony Li" <[email-masked]>
Date: Mon, 18 Aug 2008 13:06:19 -0700

Hi Iljitsch, 

|> To date, folks have claimed that the return routability of the  
|> address was
|> 'enough' security.  However, that depends on routing being secure.   
|> I hope
|> the folks in this group are aware of the reality in that regard.
|
|Security is in the eye of the beholder.

Indeed.  Understanding the state of BGP security is necessary and sufficient
to understand the level of security being offered by the return routability
check.

|In other words: in a loc/id solution you lose the return routability  
|check on the identifiers so new security mechanisms are needed that  
|are at least as strong as the (fairly weak) return routability check.  
|These need to be easier to work with and more efficient than IPsec,  
|though.

More precisely: in a loc/id solution, just filtering on the id is
insufficient.  One can emulate the previous (insecure) semantics by
filtering on the (loc, id) tuple.  

If folks feel that IPsec is unwieldy, then they're free to propose something
else.  Obviously, that's a bit out of our scope.

Tony

---

From: Christian Vogt <[email-masked]>
Date: Mon, 18 Aug 2008 15:17:42 -0700

Tony -

> filtering on the (loc, id) tuple.

Filtering on locators alone, even in a locator/ID split solution,
would actually be sufficient to emulate return-routability-flavor
security.  There is no extra benefit in additionally including the ID
in the filter unless the ID was unspoofable.  However, if the ID was
unspoofable, then there would be no reason to include the locator in
the filter.

It goes back to what you were saying earlier:  Any remote information
can be reliably filtered upon if and only if it is unspoofable.

Highly desirable would, of course, be a solution that allows filtering
exclusively based on IDs.  The benefits would be easier mobility and
multi-homing support, as well as simpler renumbering.  Yet finding a
solution that enables such filtering in a secure way is hard.

Worthwhile to note:  By "unspoofable" above I mean securely verifiable
on a per-packet basis.  This is substantially harder than host-to-host
verifiability.  E.g., a HIP host identity tag is cryptographically
verifiable by the communicating hosts, but it cannot be securely
verified by filters (or other middleboxes).

- Christian

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 19 Aug 2008 10:08:27 +0800

> Filtering on locators alone, even in a locator/ID split 
> solution, would actually be sufficient to emulate 
> return-routability-flavor security.  There is no extra 
> benefit in additionally including the ID in the filter unless 
> the ID was unspoofable.  However, if the ID was unspoofable, 
> then there would be no reason to include the locator in the filter.
> 
> It goes back to what you were saying earlier:  Any remote 
> information can be reliably filtered upon if and only if it 
> is unspoofable.
> 
> Highly desirable would, of course, be a solution that allows 
> filtering exclusively based on IDs.  The benefits would be 
> easier mobility and multi-homing support, as well as simpler 
> renumbering.  Yet finding a solution that enables such 
> filtering in a secure way is hard.

Agree. Besides, in an id/locator split solution, the uRPF can do little help
in preventing identifier spoofing, so it's more necessary to strengthen the
unspoofability of the identifier.

> Worthwhile to note:  By "unspoofable" above I mean securely 
> verifiable on a per-packet basis.  This is substantially 
> harder than host-to-host verifiability.  E.g., a HIP host 
> identity tag is cryptographically verifiable by the 
> communicating hosts, but it cannot be securely verified by 
> filters (or other middleboxes).

Why? Can you explain more? Due to the usage of the base exchange?

Xiaohu Xu

---

From: Christian Vogt <[email-masked]>
Date: Wed, 20 Aug 2008 04:41:55 -0700

[Resending.  My emails don't seem to make it to this list...]

>> Worthwhile to note:  By "un-spoofable" above I mean securely  
>> verifiable

Correct.  For a middlebox to securely perform a packet-level action
(such as filtering) based on the ID of a packet, the ID in the packet
would have to be securely verifiable based on information carried in
the same packet.  There is technology [1] that provides such
per-packet information, but most ID/locator split solutions do not.

- Christian

[1] Packet Level Authentication project at Helsinki Institute of
     Technology, http://www.tcs.hut.fi/Software/PLA/new/