Request for comment -- BCP38
Hugo Slabbert
hugo at slabnet.com
Tue Sep 27 04:37:42 UTC 2016
This seems to have split into a few different sub-threads and had some
cross-talk on which network is being described where (thanks in no small
part to my flub on John's figures and target), but this seems to be exactly
the kind of info folks are looking for but missing at
http://www.bcp38.info.
In the interest of clarity, does this roughly cover the options/challenges
people are seeing at various types of networks?
Network #1
----------
Customer has PI space. ISP A learns routes to the customer's PI space
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.
We're assuming an edge provider, i.e. the customer is not providing transit
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
populated from IRR data.
Network #2
----------
Same as #1, except while ISP A does have a valid forwarding path to the
customer's PI space via the customer link, that is *not* the active path.
Examples could be that customer prefers ingress via another link (either
with ISP A or another provider altogether) and so prepends, uses provider
communities to depref the advertisement below another path, etc.
BCP38 implementation:
Feasible Path RPF[1] should work, but AFAIK is not supported on all
platforms. Failure modes should be considered, though, and using feasible
path RPF would result in dropped traffic if the customer dropped the
announcement to ISP A in the future. If Feasible Path RPF not supported or
viable, IRR data can/should be used to generate customer interface input
filters.
Same as #1, if egress source address filtering is implemented, this
can/should be populated from IRR data.
Network #3
----------
Same as #1, except the transit provider has *no* valid forwarding path to
the customer's PI space via the customer link. IOW the customer is using
the transit provider for egress *only*, not ingress.
Feasible Path RPF is not viable. Input filters are required on
customer-facing interfaces, and can/should be generated from IRR data.
Same as #1 and 2, if egress source address filtering is implemented, this
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
for implementing uRPF are the same. Where I would consider things becoming
more challenging is on generating input filters on customer-facing
interfaces were strict or Feasible Path RPF are not viable, or egress
source address filters if those are in use.
Mark:
You mentioned the option of leveraging ROAs for validating customer
prefixes allocated by other ISPs. I must admit my RPKI knowledge needs
some love, but my understanding is that ROAs link prefixes to a given ASN,
with the ROA signed by the private key from the resource holder's
certificate. Would this validation option for PA allocations be applicable
only in cases where the customer holds an ASN to which the prefix could be
linked? In other words the prefix on the ROA would be the PA prefix
allocated by ISP B, the ASN on the ROA would be the customer's ASN, and the
private key signing the ROA would belong to ISP B, as they are the resource
holder?
Hopefully not downgrading this conversation, but lacking RPKI validators at
ISP A and a valid RPKI setup at ISP B, and assuming that the customer has
an ASN, this info could also be generated from IRR data as well, no? I
mean, dropping a /29 into a routing registry won't do much good in terms of
getting announcements accepted, but it could still be leveraged for this
use case to generate filter prefix lists, right?
If this is not tied to a customer ASN (because they don't have one) but
rather to ISP B's ASN, how does ISP A vet that a ROA-validated prefix tied
to ISP B's ASN applies to this particular customer? Absent RPKI and
falling back to IRR, same question?
Network #4
----------
Customer has broadband connections from ISP A and ISP B. If I'm not
totally out to lunch above re: needing an ASN for the customer to leverage
an ROA-based solution as Mark touched on, are we stuck in either manual
ACLs or asking or writing new implementations as John described?
On Mon 2016-Sep-26 16:04:33 -0000, John Levine <johnl at iecc.com> wrote:
...
> I realize there's no way to do it automatically now, but it doesn't seem
> like total rocket science to come up with some way for providers to pass
> down a signed object to the customer routers that the routers can then
> pass back up to the customer's other providers.
Transit touchdown interfaces
----------------------------
This is Baldur's scenario. Barring both upstreams maintaining manual
filters that cover the touchdown networks handed to their mutual customers,
it seems either Mark's or John's suggestions could be potential solutions
here?
--
Hugo Slabbert | email, xmpp/jabber: hugo at 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 at 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 at cisco.com>, Eliot Lear writes:
>> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
>> --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN
>> From: Eliot Lear <lear at cisco.com>
>> To: Laszlo Hanyecz <laszlo at heliacal.net>, nanog at nanog.org
>> Message-ID: <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589864 at cisco.com>
>> Subject: Re: Request for comment -- BCP38
>> References: <20160926180355.1229.qmail at ary.lan>
>> <dc13dbd3-051c-2239-1ecb-3f4ab43b049a at heliacal.net>
>> In-Reply-To: <dc13dbd3-051c-2239-1ecb-3f4ab43b049a at heliacal.net>
>> Content-Type: text/plain; charset=utf-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, ISP=
>> A
>> >>>>> *should* drop that traffic on the floor.
>> >>>> This is a legitimate and interesting use case that is broken by BCP3=
>> 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.=20
>> >> 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. =20
>> > 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="signature.asc"
>> Content-Description: OpenPGP digital signature
>> Content-Disposition: attachment; filename="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=
>> =HdDL
>> -----END PGP SIGNATURE-----
>>
>> --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN--
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160926/76d168ef/attachment.sig>
More information about the NANOG
mailing list