route ingress

i've been tracking some spammers through unallocated address space of late.
i'm about to have to turn on extreme-level debugging in my bgp speaker, since
what's been happening is that a route is injected "somewhere" to unallocated
space, a whole boatload of relayspam is unloaded in a matter of minutes, and
the unallocated-space route is withdrawn.

so i read with some interest the recent nanog discussions about how folks knew
that a given customer really was the owner of some prefix they wanted to use.
while i heard some good answers from some well known parties, the silence from
the ramparts was deafening.

a lot of younger ISP's inject their IGP into their EGP. we hear about this
when autoaggregation fails, but we don't hear about it when routing table
bloat doesn't cause us to focus our attention on it.

older ISP's all or mostly all know that everything they inject into their EGP
should be a nailed up static, and that the multihomed exceptions are few
enough to treat as one-off's.

however, when you set up BGP peerage with somebody, you're at the mercy of
whatever level of selectivity they use in their injections. that is, most
folks do not use RPSL or the PRDB or whatever to control what they'll listen
to from a BGP peer. the assumption of trust and competence still runs high
among people who speak BGP to each other.

so the question that's got me perturbed at the moment is, if a spammer wanted
to spam from unallocated address space using five minute windows, would YOUR
routing core allow it? subquestion 1: if the spammer is your customer.
subquestion 2: if the spammer is a customer of one of your BGP peers.
subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

i've sent reply-to to myself. i will summarize responses back to the list.

however, when you set up BGP peerage with somebody, you're at the mercy of
whatever level of selectivity they use in their injections. that is, most
folks do not use RPSL or the PRDB or whatever to control what they'll listen
to from a BGP peer. the assumption of trust and competence still runs high
among people who speak BGP to each other.

only among those who have not been burned.

so the question that's got me perturbed at the moment is, if a spammer
wanted to spam from unallocated address space using five minute windows,
would YOUR routing core allow it? subquestion 1: if the spammer is your
customer. subquestion 2: if the spammer is a customer of one of your BGP
peers. subquestion 3: if the spamemr is a customer of a distant
BGP-connected AS.

no to all, of course.

filters are your friend. filters are your friends' friend.

randy

filters are your friend. filters are your friends' friend.

Yes, but centralized database is not the answer. For one, it
is liable to be screwed up completely from time to time (that much,
InterNIC experience shows us). It is expensive to maintain; and
the problem of accuracy of the information within is quite acute.
The political implications of a cenrtalized agency are even worse;
i do not think we want a replay of the domain name debate.

The only real solution is strong cryptographical authentication of
the ownership of routing prefixes. For some reason i do not see
any serious work in that direction being done.

For now, it may be a good idea for tier-1 providers to adhere to a
procedure similar to that used (or used to be used) by Sprint: no
customer routing information is accepted before customer's border
box configuration passed inspection by Sprint staff. No-nos included
unfiltered redistribution of IGP into BGP and lack of anti-transit AS-path
filters.

---vadim

Vadim,
  Your policy above is unwise from the perspective that it seems to believe
that configuration errors are a one time problem. A more reasonable policy
is to help your customers learn how to setup filters properly, and then
filter heavily on /your/ router to make certain hat no matter what they do
they can't effect either your internal, or external routing.

for customer routes, the irr has been demonstrated to work well. not for
peers.

randy

The only real solution is strong cryptographical authentication of
the ownership of routing prefixes. For some reason i do not see
any serious work in that direction being done.

Actually, it is being done. It's not ready for implementation yet.

Tony

Vadim Antonov <avg@pluris.com> writes:

The only real solution is strong cryptographical authentication of
the ownership of routing prefixes. For some reason i do not see
any serious work in that direction being done.

This would be much easier if we had a bottom-up
hierarchical addressing structure rather than the
current top-down one.

Consider the distribution of cryptographically
authenticated connectivity maps a la NIMROD or a
multi-level LS protocol, for example, for path
authentication vs. how one would distribute and
authenticate reachability information with the
current addressing structure.

  Sean.

I don't understand how the current top-down allocation affects how that
would be done. As I see it (and I haven't spent any significant time
working on it, but it seems straightforward):
1) ARIN/whoever signs an address allocation to an entity
2) that entity signs route announcements to peers/upstreams, incuding
    who they are announced to
3) readvertisements are signed by the advertiser

Any recipient of a route can verify that the address space was properly
allocated by inspecting the address allocation certificate and verifying
the signature of the registry, and they can verify the path that
advertisement has taken to get to where it is. Thus no one can interject
a route to a network prefix that is not properly allocated, and someone
cannot steal a route advertisement for someone else's prefix. The biggest
problem with something like this is the size of the routing table in
memory (since you have to keep certificates around for readvertisements)
and in the bandwidth required for the updates.

I am not familiar with NIMROD, do you have a pointer to it?

John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
205/883-4233x7007 Huntsville, AL 35801

Sean M. Doran wrote:

Vadim Antonov ?avg@pluris.com? writes:

? The only real solution is strong cryptographical authentication of
? the ownership of routing prefixes. For some reason i do not see
? any serious work in that direction being done.

This would be much easier if we had a bottom-up
hierarchical addressing structure rather than the
current top-down one.

I quite agree with that (though i'm not convinced that "bottom->top"
allocation combined with recursive NATting is the best architecture).

However, this does not preclude doing authentication with the current
routing system.

--vadim

I am sorry, but what for do you want it? Why is not efficient to use AS
identification in conjuction to IP prefix filtering at the 1't level ISPs
(and may be 2'nd level too), based on the NIC data base.

??

"John A. Tamplin" <jat@Traveller.COM> writes:

I don't understand how the current top-down allocation affects how that
would be done.

This is a very broad issue so i will oversimplify.

Right now, in order to verify that a particular prefix is
being announced properly, one has to be able to associate
the prefix with the announcer in two directions.

Firstly, one has to walk a tree of registries from the
root towards the announcement to make sure the address has
been allocated correctly. This means that registries from
the root down have to keep some sort of credential scheme
for each entity to which it has allocated addresses,
and moreover, that those credentials are carried in
routing announcements, which is interesting when you
consider aggregation.

Secondly, one needs a routing registry which indicates
that the route has been announced following the proper
policy. Then, when you hear an announcement you have to
walk back through the policy tree to ensure that not only
the policy as registered was followed but also you need to
check processing credentials to make sure people aren't
faking up a remote AS-to-AS adjacency, for example.

With a bottom up allocation scheme, assuming something
like IS-IS on steroids as the Internet-wide routing
protocol, where there is a flat-routed (or
locally-interpreted) part on the extreme right and the
address grows leftwards away from the originating area,
one does not have to go to a registry to check whether a
particular network should be originating a particular
address. Moreover, routing will be hierarchical in
nature, in verifying policy one will generally make use of
a tree of trust in verifying the processing signatures,
although one can ask each area recursively if it had
intended the announcement to its adjacent (parent or
child) area.

Policy in a hierarchical network where addressing strictly
follows topology will be simpler to describe even in the
presence of unusual constraints, and therefore the
verification work will be simpler. Moreover, at a
distance, all you want to do is verify the presence or
absence of an area to area adjacency rather than the
presence or abence of a large number of global prefixes.
Finally, all you need is a database of unique area-id to
credentials, rather than a hierarchical database of
prefix-to-entity/entity-to-credential scheme.

As I see it (and I haven't spent any significant time
working on it, but it seems straightforward):
1) ARIN/whoever signs an address allocation to an entity

To make it clearer, try working on defining "whoever".

2) that entity signs route announcements to peers/upstreams, incuding
    who they are announced to

What do you do about aggregation, both atomic and proxy?

What do you do about pieces of an aggregate when they
appear, or more importantly, when they do not appear?

3) readvertisements are signed by the advertiser

What do you do if there is a transient change in topology
such that the chain of announcers differs substantially?

For instance, suppose you see an AS path of A B C D E for
a particular prefix, and later you see F G H I E? How do
you know this announcement is correct and should be believed?

Any recipient of a route can verify that the address space was properly
allocated by inspecting the address allocation certificate and verifying
the signature of the registry, and they can verify the path that
advertisement has taken to get to where it is. Thus no one can interject
a route to a network prefix that is not properly allocated, and someone
cannot steal a route advertisement for someone else's prefix. The biggest
problem with something like this is the size of the routing table in
memory (since you have to keep certificates around for readvertisements)
and in the bandwidth required for the updates.

Ok, so suppose someone somewhere announces 128.100.251/24.
Walk the decision tree of a number of routers, notably
ones at big exchange points, or ones at smaller multihomed
networks a couple of ASes away from some of the big
networks, and tell me what you think needs to happen.

Then make it more fun: deaggregate 9/8 at the /24 (or the
/30) level and announce it around, or try announcing huge
swaths of address space programattically with a modified
gated (for example). Where is the huge wave of
announcements caught and dealt with, and what has to cope
with such a flood of announcements?

I am not familiar with NIMROD, do you have a pointer to it?

It's in the usual place for IETF working groups,
and specifically http://www.ietf.org/html.charters/nimrod-charter.html
is what you want.

The likliest evolutionary direction of the Internet now is
something like NIMROD married to MPLS (another IETF WG)
with translation between the new stuff and old IPv4 hosts
(and to-be-considered-old IPv6 hosts) close to the edges
of the Internet.

  Sean.

Vadim Antonov <avg@pluris.com> writes:

I quite agree with that (though i'm not convinced that "bottom->top"
allocation combined with recursive NATting is the best architecture).

Randy Bush once made the comment that I live in a number
of possible future Internets. These are two possibilities, not one.

The variable-length bottom->top hierarchical network
addressing scheme I prefer eliminates the need for
translation of transport addresses. The hard work is in
resolving endpoint name to transport address.

NAT is only needed in the case where address uniqueness
and routability is not inherently guaranteed by the
transport addressing structure.

Recursive NAT is only needed in the case where the size of
a catenet is such that a number of intercommunicating
NAT-using routing super domains in aggregate use more than
the entire available address space.

NAT buys us the time to investigate technologies
considerably different from IP while retaining IP as the
lingua franca. Recursive NAT buys time in the face of
people who try to make the argument (since demolished by
HWB's graphics, I think, yes?) that we really are under
pressure to increase the number of potentially addressable
things.

However, this does not preclude doing authentication with the current
routing system.

Yes, I agree completely. However the current routing
system sure doesn't make doing that easy.

  Sean.