Request for comment -- BCP38

Mon Sep 26 21:08:27 UTC 2016

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