[191766] in North American Network Operators' Group
Re: Request for comment -- BCP38
daemon@ATHENA.MIT.EDU (Hugo Slabbert)
Tue Sep 27 00:37:48 2016
X-Original-To: nanog@nanog.org
Date: Mon, 26 Sep 2016 21:37:42 -0700
From: Hugo Slabbert <hugo@slabnet.com>
To: Mark Andrews <marka@isc.org>
In-Reply-To: <20160926210827.AD092551412D@rock.dv.isc.org>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
--67twsjhhyqtccknl
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
This seems to have split into a few different sub-threads and had some=20
cross-talk on which network is being described where (thanks in no small=20
part to my flub on John's figures and target), but this seems to be exactly=
=20
the kind of info folks are looking for but missing at=20
http://www.bcp38.info.
In the interest of clarity, does this roughly cover the options/challenges=
=20
people are seeing at various types of networks?
Network #1
----------
Customer has PI space. ISP A learns routes to the customer's PI space=20
across the customer links via BGP or even static routes.
ISP A's active forwarding path to the PI space is via the customer link. =
=20
We're assuming an edge provider, i.e. the customer is not providing transit=
=20
for further downstream networks.
BCP 38 implementation:
Strict uRPF on customer-facing interfaces should "Just Work".
If egress source address filtering is implemented, this can/should be=20
populated from IRR data.
Network #2
----------
Same as #1, except while ISP A does have a valid forwarding path to the=20
customer's PI space via the customer link, that is *not* the active path. =
=20
Examples could be that customer prefers ingress via another link (either=20
with ISP A or another provider altogether) and so prepends, uses provider=
=20
communities to depref the advertisement below another path, etc.
BCP38 implementation:
Feasible Path RPF[1] should work, but AFAIK is not supported on all=20
platforms. Failure modes should be considered, though, and using feasible=
=20
path RPF would result in dropped traffic if the customer dropped the=20
announcement to ISP A in the future. If Feasible Path RPF not supported or=
=20
viable, IRR data can/should be used to generate customer interface input=20
filters.
Same as #1, if egress source address filtering is implemented, this=20
can/should be populated from IRR data.
Network #3
----------
Same as #1, except the transit provider has *no* valid forwarding path to=
=20
the customer's PI space via the customer link. IOW the customer is using=
=20
the transit provider for egress *only*, not ingress.
Feasible Path RPF is not viable. Input filters are required on=20
customer-facing interfaces, and can/should be generated from IRR data.
Same as #1 and 2, if egress source address filtering is implemented, this=
=20
can/should be populated from IRR data.
PA space variants to Networks #1 - 3
------------------------------------
Flipping all of the above scenarios to PA space rather than PI, the options=
=20
for implementing uRPF are the same. Where I would consider things becoming=
=20
more challenging is on generating input filters on customer-facing=20
interfaces were strict or Feasible Path RPF are not viable, or egress=20
source address filters if those are in use.
Mark:
You mentioned the option of leveraging ROAs for validating customer=20
prefixes allocated by other ISPs. I must admit my RPKI knowledge needs=20
some love, but my understanding is that ROAs link prefixes to a given ASN,=
=20
with the ROA signed by the private key from the resource holder's=20
certificate. Would this validation option for PA allocations be applicable=
=20
only in cases where the customer holds an ASN to which the prefix could be=
=20
linked? In other words the prefix on the ROA would be the PA prefix=20
allocated by ISP B, the ASN on the ROA would be the customer's ASN, and the=
=20
private key signing the ROA would belong to ISP B, as they are the resource=
=20
holder?
Hopefully not downgrading this conversation, but lacking RPKI validators at=
=20
ISP A and a valid RPKI setup at ISP B, and assuming that the customer has=
=20
an ASN, this info could also be generated from IRR data as well, no? I=20
mean, dropping a /29 into a routing registry won't do much good in terms of=
=20
getting announcements accepted, but it could still be leveraged for this=20
use case to generate filter prefix lists, right?
If this is not tied to a customer ASN (because they don't have one) but=20
rather to ISP B's ASN, how does ISP A vet that a ROA-validated prefix tied=
=20
to ISP B's ASN applies to this particular customer? Absent RPKI and=20
falling back to IRR, same question?
Network #4
----------
Customer has broadband connections from ISP A and ISP B. If I'm not=20
totally out to lunch above re: needing an ASN for the customer to leverage=
=20
an ROA-based solution as Mark touched on, are we stuck in either manual=20
ACLs or asking or writing new implementations as John described?
On Mon 2016-Sep-26 16:04:33 -0000, John Levine <johnl@iecc.com> wrote:
=2E..
> I realize there's no way to do it automatically now, but it doesn't seem=
=20
> like total rocket science to come up with some way for providers to pass=
=20
> down a signed object to the customer routers that the routers can then=20
> pass back up to the customer's other providers.
Transit touchdown interfaces
----------------------------
This is Baldur's scenario. Barring both upstreams maintaining manual=20
filters that cover the touchdown networks handed to their mutual customers,=
=20
it seems either Mark's or John's suggestions could be potential solutions=
=20
here?
--=20
Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com
pgp key: B178313E | also on Signal
[1] https://tools.ietf.org/html/rfc3704#section-2.3
On Tue 2016-Sep-27 07:08:27 +1000, Mark Andrews <marka@isc.org> wrote:
>
>BCP 38 does NOT prevent multi-homed clients. Naive deployment of
>BCP 38 prevents multi-homed clients. There is NOTHING in BCP 38 that
>says you may not also accept other prefixes allocated to your
>clients.
>
>BCP 38 says accept allocated address, drop everything else.
>
>Now it should be possible with ROA's to completely automate support
>for multi-homed clients as you can cryptographically verify the
>addresses allocated to your clients from other ISPs / RIRs.
>
>The DHCP server could generate a CERT for every allocation it hands
>out if a client requested it. This really only needs a DHCP option
>to be defined to request this.
>
>Just as it is possible to secure BGP it is possible to secure BCP 38
>additional prefixes.
>
>BCP 38 is INGRESS filtering from your customers. Treating your own
>offices as a "customer" is also recommended.
>
>In message <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589864@cisco.com>, Eliot Lear wr=
ites:
>> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
>> --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN
>> From: Eliot Lear <lear@cisco.com>
>> To: Laszlo Hanyecz <laszlo@heliacal.net>, nanog@nanog.org
>> Message-ID: <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589864@cisco.com>
>> Subject: Re: Request for comment -- BCP38
>> References: <20160926180355.1229.qmail@ary.lan>
>> <dc13dbd3-051c-2239-1ecb-3f4ab43b049a@heliacal.net>
>> In-Reply-To: <dc13dbd3-051c-2239-1ecb-3f4ab43b049a@heliacal.net>
>> Content-Type: text/plain; charset=3Dutf-8
>> Content-Transfer-Encoding: quoted-printable
>>
>> Guys,
>>
>> You're getting wrapped around the axle. Start by solving the 90%
>> problem, and worry about the 10% one later. BGP38 addresses the former
>> very well, and the other 10% requires enough manual labor already that
>> you can charge it back.
>>
>> Eliot
>>
>>
>>
>>
>> On 9/26/16 8:44 PM, Laszlo Hanyecz wrote:
>> >
>> >
>> > On 2016-09-26 18:03, John Levine wrote:
>> >>>>> If you have links from both ISP A and ISP B and decide to send
>> >>>>> traffic
>> >>>>> out ISP A's link sourced from addresses ISP B allocated to you, IS=
P=3D
>> A
>> >>>>> *should* drop that traffic on the floor.
>> >>>> This is a legitimate and interesting use case that is broken by BCP=
3=3D
>> 8.
>> >>> I don't agree that this is legitimate.
>> >>>
>> >>> Also we're talking about typical mom & pop home users here.
>> >> There are SOHO modems that will fall back to a second connection if
>> >> the primary one fails, but that's not what we're talking about here.
>> >>
>> >> The customers I'm talking about are businesses large enough to have
>> >> two dedicated upstreams, and a chunk of address spaced SWIP'ed from
>> >> each. Some run BGP but I get the impression as likely as not they
>> >> have static routes to the two upstreams.
>> >>
>> >> For people who missed it the last time, I said $50K/mo, not $50/mo.=
=3D20
>> >> Letters matter.
>> >
>> > This doesn't have to be $50k/mo though. If the connections weren't
>> > source address filtered for BCP38 and you could send packets down
>> > either one, the CPE could simply start with 2 default routes and take
>> > one out when it sees a connection go down. This could work with a
>> > cable + DSL connection even. It would be easy to further refine which
>> > connection to use for a particular service by simply adding a specific
>> > route for that service's address. This would be a lot better than
>> > having to restart everything after one of the connections fails. =3D20
>> > This would provide functionality similar to the BGP setup without any
>> > additional work from the service provider. People can't build CPE
>> > software that does this type of connection balancing because they
>> > can't rely on this working due to BCP38 implementation. In my
>> > experience the only way you can get people to stop source address
>> > filtering is if you mention BGP, but BGP shouldn't be required to do
>> > this.
>> >
>> > -Laszlo
>> >
>> >>
>> >> R's,
>> >> John
>> >>
>> >
>> >
>>
>>
>>
>> --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN
>> Content-Type: application/pgp-signature; name=3D"signature.asc"
>> Content-Description: OpenPGP digital signature
>> Content-Disposition: attachment; filename=3D"signature.asc"
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2
>>
>> iQEcBAEBCAAGBQJX6YIpAAoJEIe2a0bZ0nozGHAH/3EXMt2/t68dgB92RPYyVSHR
>> 46WpPPOEhD1Qd1s6MW4mhzhWWmv99RGwPm1ZXVzE9iIpMkptXEuzbsHz1V7mjsao
>> 5MkIyzvWgF6qpe1kI1xZp2xoDa++XjfJqwUMg0swxji7idjkMILw6buE70lubOCB
>> Uu2Y6uGPCnsIEcD106AxJYkP91BlBkBRPAFoBjbdZKRTs3+TYQgxS815qviSiDux
>> MXhdxgpo8yg/B8knmjQwwIcG3+Ug5FvkPJyz88GQKwwU6nEIKUn2Zf3U/vw2vQTN
>> 3K+DlRIGy6ZXani4ab58pswrrhFl9P9bocRom+cJQAqb3JwR60NuUX1/YKeTv2o=3D
>> =3DHdDL
>> -----END PGP SIGNATURE-----
>>
>> --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN--
>--=20
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
--67twsjhhyqtccknl
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCgAGBQJX6feSAAoJEFsnhBAb2KmAyroP/2R1n395hKuDYyVBg+y2372d
X9qQwF5xdC+hycIWuP2EZ+AAuxgGEA/U5RbEVdckfSoIVyicnMydscw5KCOUQf2m
f32ozwXL9L7knDMnMSqdT0UjiBqX/O01M9dO6LtPKjjGtuVvfaWMRZmzp/uBGUll
kZ7sWElLcoGtYz+InFlsheA6DCbHJFiZEkYWlwlzVtfGIMJMims3gNCLGDgm5svm
ZDIOlFJR/rRvJ+j9Hpw8lIwQyFgWDHXb9a81PTpWrVvWyX1ixCi5ysCraYx+VVYg
I/z3YGe6mJiPxAdmj+dDi09Myo+u0IEGqe0w7+h25M+VNiq5gYbYFlXNCIGIdmSm
fnR2Ohuv/rqBcTTOB/1on0/IRXf4LhQnnHPqxrF2OQk8r93BgOSrzXOI86cQD1HR
4RNZWGzVPPfQzRtaNBH8iKqxXsSVBo8eViKn/EXIKRoJzW0JzvoI5t1vx6hV47B/
OVGmHZfCThof3/Gzv4ehHQU3gN8nejzGY09zHS9M/ts0VnG4s7f+vlHXH07dgWKD
X7ao5GUba8hFd4FkU4pna06tJRLNsfkZ7+1mjWFB+2ZUt6STKS8KdhG9VvabB+J3
9gbDRXLq88G39H5nF62VgKGwmn9jMGAyzcPIgbga/mVs1mScjj9OSmlNULM/G4XY
kY9Fmceoocaaiui5sR62
=amqQ
-----END PGP SIGNATURE-----
--67twsjhhyqtccknl--
