Subject: RE: A few comments on Site-Local Useage

From: "Michel Py" <[email-masked]>
Date: Tue, 5 Nov 2002 11:34:53 -0800

Bob,

> Bob Hinden wrote:
> It seems to me that from a reachability point of view
> there isn't too much difference between using site-local
> addresses and having a firewall that blocks traffic from
> one set of global addresses and another.

This could be debated forever, and I don't think the discussion would be
productive as the security implications of site-local addresses are
dealt with at layer 9.

Here's an example:

- You are the security designer of a utility company.
- By using a combination of beginner's luck, skill, social engineering
and other things, a 15 year-old manages to get in one of the breakers
and shuts down power 15 blocks down main street. Not funny enough, so
the kid goes bragging about it on some IRC channel and it makes it to
the local newspaper.
- Suddenly your seat will become too hot for a certain part of your
body.
- Worse, if someone trips in the dark and breaks their back, they're
going to sue the company for negligence and your management will can
that body part we were talking about earlier.

All of this for one reason. One.
Because, in the aftermath of the outage, there is always going to be
some security consultant to say to your senior management:

"THIS WOULD NOT HAVE HAPPENNED IF YOU USED PRIVATE ADDRESSES".

This reason alone is good enough for network managers to keep using
private addresses, and they will continue doing it regardless of what
half of this mailing list thinks.

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Michel Py" <[email-masked]>
Date: Tue, 5 Nov 2002 23:43:56 -0800

Bill,

% Michel Py wrote:
% Rationale: ambiguity is a fail-safe for routes that leak in the DFZ
even
% though they were not supposed to and for ISPs that don't filter them
% even though they were supposed to.
% If we could add to this black hole a preconfigured prefix-list for
each
% peer that would deny FEC0::/10 ge 10 (1) that would likely be good
% enough to let ambiguity go and we would make a step towards globally
% unique site-locals.
% (1) I am thinking about something like the default deny at the end,
% except that it would be at the beginning and would be effective even
% though there is no prefix-list applied to the peer. Something that
would
% require a separate command and a confirmation to de-activate. Why
would
% one want site-locals in BGP anyway?

> Bill Manning wrote:
> per interface or per-peer? (will require a better understanding
> of default behaviour of routing protocols)
> if per-peer, which routing protocol?

That's a good question, and I'm not sure I have a good answer.
Let's try this:

Rationale 1:
This black hole to FEC0::/10 that Bob mentioned earlier is a good idea,
but it does not achieve much in practice as it would be a well-known
mechanism and the hacker would announce FEC0::/11 instead and bypass it.
What we really need is to blackhole the route itself. The same reasoning
applies if the route leak is a result of a snafu from the legit network
admin, because the route being leaked is probably going to be FEC0::/48
or some /48 within the range, which will not go into Bob's blackhole
either.

Rationale 2: Site-locals are routable within the site, which more or
less means allow with IGP, and not routable outside of the site, which
more or less means deny with BGP. I think the answer to "which protocol"
is definitely BGP, and possibly eBGP.
I have not thought the process much but I think that site-locals should
not be carried over iBGP, but over IGP only. Any takers on this?

Thought process:
I thought this as a BGP animal, so naturally it was on a per-peer basis.
The two reasons I would still lean towards this are:
- The amount of peer traffic to match against is very small compared to
the amount of generic traffic.
- Per-interface would require further processing as identifying the
traffic as being BGP, then decapsulating the packet and inspect the
actual route inside, sounds awful to me, NAT-like ALG.

In short:
> per interface or per-peer?
Per-peer.

> if per-peer, which routing protocol?
BGP, possibly eBGP only, to be discussed.

Hope this answers the question,
Michel.