RE: draft-ietf-opsec-infrastructure-security-01 - InfrastructureHiding

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 3 May 2007, Smith, Donald wrote:
> When BCP38 was written in 2000 some ingress filtering concepts had 
> been adopted by many ISPs but it was not the Best "Current" Practice 
> nor the Best "Common" Practice. It has since been fairly widely 
> adopted but I am not sure that today it has been implemented on more 
> then 50% of the router interfaces. Would 50% adoption qualify it as 
> a "common" practice?

How does deploying BCP38 towards your customer cause bad effects to 
the customer?  Any loss of debuggability of network failures?

(I'm excluding scenarios where the customer is using multiple prefixes 
from multiple ISPs here, because I doubt you'd be disabling that via 
uRPF in any case.)

AFAICS, BCP38 deployment is harmless to the customer.

Infrastructure hiding?  Extreme infrastructure hiding would very 
likely hurt the customer.  More difficult to debug network failures. 
More difficult to diagnose network performance issues.  It also 
increases the provider's support load because you have to do more work 
yourself and you'll get more false reports due to the users not being 
able to correctly diagnose the responsible party of a failure.

> > Further in the thread, people have stated that most of these
> > techniques have already been deployed in many large provider
> > networks.
> > Could you please name a couple?  I'd like to run traceroute etc.
> > through them to see if my requirements (as a customer of said transit
> > operators) for usability are being met or not.
>
> With out providing details I believe ALL of the tier1 ISPs
> have implemented some infrastructure hiding.
...
> Traceroute through various networks and see if they give you the
> INTERFACE ip or the loop back ip in the icmp ttl expire message. Many
> today return the loopback ip not the interface ip.
> This is an additional layer or level of hiding.
> Not returning ANY ttl expire message provides an additional level or
> layer that you may not be comfortable with but is very common in mpls
> clouds.

I think this is the key problem at the moment.  'Infrastructure 
hiding' is too broad a term.  At the minimum, the document should 
define different "levels" of infrastructure hiding (from 'try to hide 
everything' to 'hide almost nothing') so that we could have a more 
sensible discussion and decide which ones we can recommend as a BCP 
and which not.

I'm pretty sure that most folks are OK with some degree of 
infrastructure hiding, but we can't just agree that that degree is 
because we're talking past each other.

I did do traceroute across multiple Tier1 providers, and many of them 
provided useful traceroute responses at least on a router granularity, 
and those routers also answered to ping.  That seems like a good 
starting point for considering what should be open.

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