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

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

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 6:37 AM
> To: gmj@pobox.com; ericb@digitaljunkyard.net
> Cc: opsec@ops.ietf.org
> Subject: RE: Dropping stealthing from opsec; Anyone for a 
> little I>R<TF
> wo rk ?
> 
> 
> George Jones 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.


> > 
> > No.  The point is to explore ways of making it impossible for anyone
> > beyond the edge of a network to address packets to any of the
> > interfaces of the core routers and have them successfully routed
> > there.  If you can't get packets there you can't attempt a DoS, you
> > can't attempt management functions, etc.
> 
> 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. (TTL timeouts, spoofed bgp or other service requests)

> 
> Moreover, if you can't get packets into the core, then it seems fair
> to say that the core doesn't actually do much, since its primary
> purpose would otherwise have been to forward the packets that do go
> into the core.  If nothing can get there, then utilization is likely
> to be pretty low indeed.
> 

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.


> ericb@digitaljunkyard.net writes:
> > jc> I'm not sure I understand the point of this[1], but 
> please do consider
> > jc> the effect of such a plan on path MTU discovery.  The 
> ICMP messages
> > jc> from within the core do need to make it out to the 
> sender in _some_
> > jc> form.
> > 
> > Path MTU Discovery should not really be needed on modern Internet
> > backbones.  Every path I've taken in recent times has made it across
> > the backbone without chunking down from the Ethernet max.  
> If there's
> > a bottleneck, it's outside the core.
> 
> Yeah, I'd like to think so, too, but there are at least three
> considerations here:
> 
> 	1.  Accidents happen.  Path MTU Discovery helps prevent abject
>             failure in the event of misconfiguration.  If we break it,
>             then we're saying that things _always_ must be configured
>             properly, and, based on history, that seems like an
>             untenable plan.
> 
> 	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 ... )

> 
> 	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.


> > jc> [1] It's not just to hide the IP addresses, is it?  
> That'd just be
> > jc>    security-by-obscurity.  I don't think that treating 
> IP addresses
> > jc>    as secrets is a viable plan.
> > 
> > Think of the phone network.  When's the last time a kid successfully
> > whistled 2600?  You don't see red boxes around anymore.  Do you have
> > ANY idea what the path of the last long distance call you made was?
> 
> That's a completely different story, and you're not addressing that at
> all.  2600 + KP + ... + ST hasn't worked in a long time (in the US at
> least) because the architecture of the system was changed -- the
> interswitch trunks used to signal calls using in-band tones (called
> "AC" or "SF" signaling).  It doesn't work *now* because they
> completely removed the signaling from the in-band path.  It's now done
> via what's called "common channel signaling," which means that the
> signaling for multiple voice channels travels via a common (and
> separate) channel.  In many cases, that common channel is even via a
> physically separate set of wires.
> 
> What this all means is that the Internet is still in the SF era
> architecturally.  What I think you're proposing is to place 2600 Hz
> notch filters at the entry and exit of the network.  This is not at
> all the same thing as what the modern telephone system does to solve
> the problem.  If you want to move the signaling out of band, then
> you'll have to move it out of band -- separate circuits.  (And as a
> router-head, I'd really object to that.)
> 
> And, for what it's worth, a notch filter on the *output* of the
> network does no good.  You need one on the *input* in order to protect
> the network.
> 
> > The Internet (in a very tall Ivory Tower sort of way) should be the
> > same.  You should buy service, and inject packets into the cloud.
> > They should come out near your destination.  And you should neither
> > know nor care what path your packets took.
> 
> Except, of course, when it doesn't work.  At a minimum, I need to know
> which pinhead I should be yelling at.  In practice, though, I need to
> know quite a bit more, since many problems that occur are quite a bit
> more subtle, and obscuring the network just gives the tech at the
> other end one more reason to say "well, it works for me."
> 
> > You don't know the MAC address of a switch in the middle of Google's
> > datacenter, and you don't care.
> 
> Correct, but not really relevant.
> 
> I don't care about the IP addresses of the routers in the middle,
> *except* as stable identifiers that I can report to someone who can
> fix the problem.
> 
> If you want to scrazzle the IP addresses at the border, I suppose
> that's fine.  I don't think it fixes any problem at all, though.
> 
> >  Heck, you can't even find out what it
> > is without either breaking one of their boxes or abusing 
> protocols in
> > interesting ways.  Similarly, you don't know the path that 
> your packet
> > took, how their HSRP is working today, or what STP has pruned this
> > time.
> 
> Ah!  But that's not true.  I do know something about the path my
> packets take today, and the information it reveals is very important.
> Is my packet bouncing back and forth between internal routers?  If so,
> then there's a forwarding loop.  Is the path it's taking wildly
> unstable?  If so, then there's some sort of internal routing protocol
> failure.  Is it getting ditched at the boundary between the three or
> four ASes that my packets have to cross?  If so, then it might be BGP
> trouble.  Is it right at the last hop?  Maybe the customer at that far
> end has falling off the net.
> 
> Now, I neither know nor care whether they're using HSRP (I'd certainly
> hope it's not used anywhere near the core, but I guess it's not my
> problem) or STP (how'd that get in there?), but I'd very much prefer
> that my ISP not treat me to the Mushroom Theory.
> 
> Note that this information loss would affect both _users_ and
> _operators_.  The result would be that ISPs would not be able to "see
> into" each others networks for diagnostic purposes.  That'd be bad.
> 
> > So as long as everything works the way that it should 
> (which is a huge
> > caveat), you neither know nor care what IP path your packets take
> > across the core.  It's just a huge black cloud, and you 
> cannot whistle
> > 2600.
> 
> Traceroute != blue box.
> 
> The analogy is false.  If you'd argued to keep IP-based routing
> traffic (OSPF, BGP) from entering the core from the outside, then I'd
> agree.  But ICMP messages leaving the core just not the same thing.
> 
> -- 
> 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
>