RE: Dropping stealthing from opsec; Anyone for a little I>R<TF wo rk ?

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

And since the goal is to prevent external systems from talking
directly to the cores the firewalls/filtering routers that
are blocking/disallowing this private address space are HELPING;-)

In fact FULL edge rfc1918 filtering would prevent anyone outside the
core from ever addressing your core directly (via ip).
 

Donald.Smith@qwest.com GCIA
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC
(coffee != sleep) & (!coffee == sleep)

> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson@sun.com]
> Sent: Friday, August 01, 2003 9:00 AM
> To: Smith, Donald; gmj@pobox.com
> Cc: opsec@ops.ietf.org
> Subject: RE: Dropping stealthing from opsec; Anyone for a 
> little I>R<TF
> wo rk ?
> 
> 
> Smith, Donald writes:
> > > > On Thu, 31 Jul 2003, James Carlson wrote:
> > > > > [1] It's not just to hide the IP addresses, is it?  
> That'd just be
> > > > >     security-by-obscurity.  I don't think that treating 
> > > IP addresses
> > > > >     as secrets is a viable plan.
> > 
> > Not secret, NOT routable. You would not be able to route 
> packets from
> > outside (edge/border)
> > to the core as a customer or peer.
> 
> The problem with non-routable (e.g., RFC 1918) addresses used on
> packets from the core is that they're all too helpfully filtered away
> by well-intentioned (but sanity-sapping and network-balkanizing)
> firewalls.
> 
> In other words, the protocols just plain break, and there's no
> workaround.
> 
> > > I must be missing something essential here.  How do packets coming
> > > *out* of the core have anything to do with attackers 
> getting packets
> > > *in* to the core?  Why would we care at all about packets 
> coming *out*
> > > of the core?
> > 
> > As many of us have seen the cores make great reflectors if 
> you can get them
> > to send packets
> > to a spoofed address.
> 
> Excuse me but: huh?
> 
> What is the threat scenario envisioned here?  The Bad Guy sends a
> really big packet with a spoofed source address in the hope that the
> core generates an ICMP too big message back to a victim, perhaps?
> This begs a lot of questions:
> 
> 	- Why wasn't that spoofed (victim) source address filtered out
>           to begin with?  This is already documented in RFC 2827 / BCP
>           38.  I don't think we need another BCP to say what this BCP
>           says.  (And if ISPs ignore RFC 2827, they'll clearly ignore
>           anything that we write here.)
> 
> 	- If it's really the case that Path MTU Discovery is "never"
>           needed in the core, because the links are "always" correctly
>           configured, then how is it possible that the attacker's
>           packet can ever be reflected in this way?
> 
> 	- Why is such a packet emanating from within the core itself
>           more hazardous than having it come from an edge router?
> 
> 	- What exact harm does the victim suffer?  What is the threat?
> 
>         - If an attacker wanted to do this, and spoofed sources
>           weren't properly filtered, why wouldn't he just spoof the
>           router's source address and send this nasty ICMP message
>           right to the victim?  What benefit does he get by using a
>           middleman?
> 
> > (TTL timeouts, spoofed bgp or other service requests)
> 
> Let's separate these a tad:
> 
> 	TTL timeouts:
> 		- Attacker sends packet with bad source address
> 		  (not filtered by RFC 2827), and short TTL.  Victim
> 		  gets expiry message.  What problem is caused?
> 
> 	Spoofed BGP:
> 		- How?  BGP runs over TCP, and, if exposed at all,
> 		  needs to be secured with the MD5 option or (perhaps)
> 		  IPsec.  It isn't as if you can inject any requests
> 		  here, or even mount RST-sniping DoS attack.
> 
> 	"Other service requests":
> 		- Please elaborate.  Are there other services that
>                   lack appropriate security mechanisms?  If so, then
>                   why not fix them?
> 
> > The core would continue to forward packets. This addresses 
> the fact that
> > customers
> > do not (except PERHAPS in troubleshooting) need to know 
> what path the
> > packets they are sending took.
> 
> That seems to be a rather big exception to me.
> 
> > > 	2.  Some RFCs require the use of Path MTU Discovery.  You're
> > >             going to have to ... um ... "harmonize" with those v6
> > >             standards.
> > 
> > This stealthing requirement will require rfc violations. 
> That is a given.
> > (ignoring ttl timeouts, no reply to icmp echo requests, no 
> resets on closed
> > ports ... )
> 
> That'd be my stop.
> 
> There is, I think, a world of difference between discarding data
> destined directly to an internal router from the outside world (which
> would fall under the broad definition of "firewalling" and would
> likely be best done at the edges rather than the middle of the
> network), and violating the requirements of RFC 1812.
> 
> > > 	3.  Packets leaving the core have nothing whatsoever to do
> > >             with whether the core can be attacked.  
> Attacks are based
> > >             on packets coming in.  ICMP errors leaving 
> the core don't
> > >             carry attacks back into the core.  (Unless, of course,
> > >             we're assuming that the source IP addresses 
> are "secrets,"
> > >             and then we're back to security-by-obscurity.)
> > 
> > If you can cause a core router to respond to stimulation as 
> noted above they
> > make good reflectors.
> 
> We're not talking about reflection in any of the normal senses here.
> These are *error* responses that differ greatly from the original
> packet sent.
> 
> George Jones writes:
> > On Fri, 1 Aug 2003, James Carlson wrote:
> > 
> > > I must be missing something essential here.
> > 
> > The idea is simple.   The core becomes a black box.
> > No direct communication possible between core and
> > anything beyond the edge.
> 
> But why?
> 
> > >  How do packets coming
> > > *out* of the core have anything to do with attackers 
> getting packets
> > > *in* to the core?  Why would we care at all about packets 
> coming *out*
> > > of the core?
> > 
> > I'll grant you that one-way communications coming out of the core is
> > not as much of a risk...useful for mapping and diagnostics 
> at most...I
> > think we'd achieve most of benefit by disallowing inbound...
> 
> "most"?
> 
> Is it possible to specify precisely what benefit is obtained by
> disallowing outbound messages?
> 
> > but I
> > think we're going to break some fundemental assumptions 
> about routing,
> > end-to-end connectivity, etc.
> 
> Indeed.
> 
> -- 
> James Carlson, IP Systems Group                
> <james.d.carlson@sun.com>
> Sun Microsystems / 1 Network Drive         71.234W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 
> 781 442 1677
>