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

["Smith, Donald" <Donald.Smith@qwest.com>]

My BCP38 reference was an example of a BCP that was written before it was a best common practice.
As for hurting the customers some were impacted when ISPs went to loose mode.
Some asynchronous service providers, such as satellite providers, were using private address space as the source ips. We have seen other times where URPF caused issues. Strict mode is generally not used in peering links but can be used in customers that are dual homed. Both Cisco and juniper have provided methods for that.
 
I think you idea of different levels of infrastructure hiding is a good idea.
 
 
 
donald.smith@qwest.com giac

________________________________

From: Pekka Savola [mailto:pekkas@netcore.fi]
Sent: Thu 5/3/2007 11:41 PM
To: Smith, Donald
Cc: Tony Rall; opsec@ops.ietf.org
Subject: RE: draft-ietf-opsec-infrastructure-security-01 - InfrastructureHiding



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



This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.