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

[James Carlson <james.d.carlson@sun.com>]

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