The MPLS WG Archive

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 22 Mar 2004, Eric Rosen wrote:
> > Destination address verification checks (disallow anything coming to
> > your routers) at the border, however, is something that is not as
> > simple
> 
> One thing you might be able to do is: 
> 
> - create a set of loopbacks from a particular address range, 

You need to care for all the point-to-point addresses on your routers 
as well, unless you implement the bullet point below, because they 
could be targeted externally as well.

> - a  decapsulator  doesn't  accept  encapsulated  packets  unless  they  are
>   destined for an address within that range

Was this an addition or a new proposal?  It isn't in the current doc
at least, I think.  Note that making such configuration might be
similarly difficult & have performance issues if your loopbacks just
wouldn't be nicely aggregatable, and you'd have to list them as 10-100
different entries.  This is actually very commonplace AFAIK.
 
> - filter  any packet  entering the network  from outside with  a destination
>   address in that range. 

Right.  And there are some concerns about how feasible this is, and 
whether ops folks are/would be doing this (all of those deploying IP 
or GRE tunneling!).
 
> > when  in place,  source-based  decapsulator checks  eliminate the  threats
> > which can be eliminated 
> 
> Yes, but on the other hand: 
> 
> - possible performance implications
> 
> - presumption  that some  higher  layer is  signaling  the allowable  source
>   addresses 

Both of these true, even though I don't personally see the (potential)
problem with performance implications; the implementations will have
to do a form of processing/acls in any case.  And the presumption for
signalling can be considered a feature as well :).

> So what we are arguing about now is whether the IETF should
> determine the proper set of tradeoffs and try to force it on the
> users, or whether the users should be able to determine their own
> set of tradeoffs (giving them more flexibility, but raising the
> chances that an insecure configuration will be created).

Yep, that's pretty close to the mark.  And that's not necessarily a 
bad idea when security-by-default is concerned. :)

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