Request for comment -- BCP38

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>