New ISP to market, BCP 38, and new tactics

Mailman List Mirror (Read Only)
1

Although I've posted to this list before, I don't want to waste your
time. This is an ops question, so I'm looking for direction, off-list if
necessary.

We are a *very* small I-SP, and am just now being put in the position to
be a backup transit for a client.

Currently, our 'upstream' advertises our route for us, 208.70.104.0/21
time, the upstream has had issues allowing me to do so.

I've also been advertising 2607:f118::/32 via BGP peering to kind people
who have been sensitive to the lack of my 'upstream's' inability to
provide me with native access.

Now, I am about to force my 'upstream' to allow me to bring my
advertisement (v4) back to me, I would like off-list feedback of any/all
documentation that I should be aware of regarding filtering.

I've proven that my 'upstream' doesn't do pull-up routes, doesn't filter
BOGON, and given that they have no clients other than myself that have
their own IP space, most likely is not capable of doing anything beyond
a simple peering session.

I've done much research on RPSL, BCP 38, and other basic filter methods
(and from a systems standpoint, I always follow an
allow,allow,default-deny approach) , and I am willing to follow all
standards and recommended practises to ensure compliance with current
Internet standards.

Although we are small with minimal resources, I feel that touching this
list is my best approach to ensure that when I do begin advertising
routes, I conform to the most practical, realistic and best current
common standards regarding IPv4 route advertisement and filtering.

I hate being a 'rat', so I won't state who does what for AS14270 (on the
v4 side of things). I have a 100Mbps fibre link from Cobourg Ontario, to
_provider_ in 151 Front Toronto. My 'new' connection (which I control),
is a direct link to Hydro One.

I am open to bandwidth/connection options regarding this feed to
Toronto, if you are commercially inclined,

Thanks,

Steve

2

Raoul Bhatia [IPAX] wrote:

hello steve,

Steve Bertrand wrote:

I've done much research on RPSL, BCP 38, and other basic filter methods
(and from a systems standpoint, I always follow an
allow,allow,default-deny approach) , and I am willing to follow all
standards and recommended practises to ensure compliance with current
Internet standards.

did you receive off-list replies? do you mind replying with a summary
of your findings to the list? i would also be interested in this subject
thou i will not be able to work on this during the next couple of
months.

Yes, I did receive a few very kind off-list replies.

The feedback was based mainly on the fact that I have a small number of
address blocks, and few connections to the Internet. In summary:

- implement BCP 38 by using ACLs on outward facing interfaces by
permitting anything within my (or my client's) address space as source,
and log/deny the rest (which is my personal standard per my OP)

- on all client-connected interfaces, ensure that the prefix(es) you
supply them with is found in the source address for packets inbound, and
deny the rest

- for smaller *SPs, ACLs is the way to go, as with only a few prefixes
and a limited number of connections to the Internet, manual management
of filters is easily maintained. Inbound ACLs can be put in place when a
new client is provisioned, and for a small shop without the need or the
resources, strategies such as uRPF are not advised

- pay attention to uRPF ("and the like"), as manual ACL management is
not scalable. It pays to keep up with what the "big boys" are doing.
Having knowledge of scalable methods, while utilizing a basic approach
will allow for an easier transition in the event of quick
growth/acquisition/new job.

- ensure you only advertise your own block(s) via BGP. allow-allow-deny
approach

- regarding BGP, scrutinize, but deny-by-default anything longer than
/24. (With IPv6, I don't know of any standard, so I filter above /48 and
I have 1579 and 1422 routes with two peers)

The above is a summary of feedback from others. I have a few that I
already do personally, but remember that I don't even advertise my v4
space myself yet:

- peer with Cymru, and null route BOGONs
- implement a pull-up route
- on all interfaces, 'get rid of' inbound traffic with a source within BOGON
- inform clients of their broken VPN connections, when you see private
IP space being sent via their assigned default gateway (which of course
is just an alert, because it has already been null0'd)
- always develop the closest-match allow filters you can, and implement
with an explicit deny. If anything, for visual purposes
- never be afraid to ask for help
- be confident, but always assume someone knows more than you do
- and most important (IMHO), always acknowledge and be able to admit
when you have made a mistake.

Hopefully this summary is ok. Thanks to all those who did reply off-list.

Steve

3

For all the kind folk who have been asking how my project is going, I'll
summarize here.

- I've enabled strict uRPF filtering on all interfaces that I am certain
what the source will be.

- I've implemented a mix of loose uRPF combined with ACL's on interfaces
that I know have multi-homed clients

- On all interfaces that run the risk of blocking traffic by accident,
I've implemented strict inbound ACL's for known-bad (combined always
with Team Cymru BGP learnt bogons), and with logging counter ACLs for
all other traffic. After a couple more days, I should be able to focus
more strictly on these interfaces

- I've made significant changes to my 'core', moving from static routes
to an iBGP mesh over OSPF learnt loopbacks. This will allow me to
implement a couple of host-based routing daemon boxes for the easy
insertion of sinkhole routes in the event of significantly bad
behaviour. With my scripting knowledge, preparing a recommended sinkhole
route for insertion, ready for admin approval will be easy, and so will
having the route removed automatically (or manually) if the attack has
ceased. I like the idea of traffic flowing to a host-based machine to
null as opposed to null'ing it on the router, as (from what I can tell)
it will make it easier to track the flow of the problem ingress and egress

- Currently, (as I write), I'm migrating my entire core from IPv4 to
IPv6. I've got the space, and I love to learn, so I'm just lab-ing it up
now to see how things will flow with all iBGP v4 routes being
advertised/routed over v6.

The division of the v6 space still overwhelms me, so I guess I'll do
what someone else stated in another thread if I mess this one up: go to
ARIN for another 1000 /32's :slight_smile:

(no, I'll learn from my mistake, and be ready for next one)

Cheers, and thanks!

Steve

4

Don't advertise v4 prefixes in v6 sessions, keep them separate.

If you do, you have to do set next-hops with route maps and things, it's kind of nasty.

Better to just run a v4 BGP mesh and a v6 BGP mesh.

5

Nathan Ward wrote:

6

MPLS - "The MP is for Multi Protocol!"

Otherwise, no, you don't get to use IPv6 addresses as next hops for IPv4 routes, which I think is what you're asking to do.

Run IPv4 and IPv6 in parallel, iBGP for v4, iBGP for v6. Same for eBGP to peers/customers.
Running v4 and v6 in one BGP session is weird and is asking for confusion, IMHO.

You get the same with OSPF - you run OSPFv2 and OSPFv3 in parallel.

7

Agreed. Keeping it separate works very well. Can be the same interface
sure... but do it as a separate session.

...Skeeve

8

Skeeve Stevens wrote:

Agreed. Keeping it separate works very well. Can be the same interface
sure... but do it as a separate session.

Yeah, that's what I thought, and that is exactly what I've been doing
thus far.

I was hoping to have a v6-only core, but in order to get the current
project done, I'll have to stay with your (and Nathan's) recommendation.

I'm not ready for MPLS (but I am interested in the theory of it's
purpose), so when I'm done what I'm doing now, I'll look at it. At that
time, if implemented, I'll be the most complex, smallest ISP in Canada :wink:

This has been an awesome journey, and I've learnt an immense amount via
all of the recommendations, reading and exercising.

Thanks guys,

Steve

9

If you can push v4 over it (other than through a NAT/tunnel/etc.),
then it's not a v6-only core :slight_smile:

The real question is whether you're going to route natively in v4,
or do a v4-in-v6 tunnel of some sort,
or a v4-in-Layer2-in-v6 tunnel of some sort,
or do NAT,
or use MPLS as a Layer 2ish core.
If you're doing MPLS, you'll need to figure out if you can run _it_
with purely v6 gear supporting it, or whether you'll need to run v4 to
make all of your MPLS vendors happy, but that doesn't need to be
publicly routable v4 carrying the entire Internet's routing tables on
it; you can leave the Internet inside a large MPLS VPN if you want.

10

Suffice it to say that some vendors are already implementing
'draft-ietf-ospf-af-alt-06.txt', which allows OSPFv3 to
handle multiple address families, including IPv4.

But this still runs over an IPv6 link. I'd still recommend
running IPv4 and IPv6 IGP's separately, unless the IGP
integrates both protocols, as in the case of IS-IS.

Cheers,

Mark.

11

Well, having a v6 core will prevent from you running MPLS,
as a v6 control plane for MPLS is not yet implemented by the
vendors today.

A draft for this is already out, though - 'draft-manral-
mpls-ldp-ipv6-02'.

Cheers,

Mark.