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

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

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

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.

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.

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

> 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