Re: Request for comment -- BCP38

[Jay Hennigan]

On 9/26/16 9:37 AM, Hugo Slabbert wrote:


On Mon 2016-Sep-26 12:25:58 -0400, John R. Levine  wrote:


I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."



I myself am talking about the latter and included the option of PI
space to cover that (although I guess at some point this can be made
fly with PA space from another provider if both providers are willing
enough to play ball), though from the $50/mo figure John listed, I'm
assuming he's talking about the latter.


Who said $50/mo?


Apparently I need even more caffeine that I first imagined...

If we're talking about networks with that kind of MRC, is it really that
far of a stretch to require PI space for this?  Then again:  If we're
talking about that kind of MRC, then I'm assuming ISP A can be coaxed to
allow explicit and well-defined exceptions on the customer's links.

This discussion started wrt to COTS dual-ISP routers though, as
mentioned in Ken Chase's message, no?  Where I'm assuming we're talking
about mom-and-pop operations rather than a $50K/mo business account.


This is getting insanely silly, especially for this list.

A $50K/mo customer should have PI space and announce via BGP to both 
(all) upstreams. He isn't going to do this with a COTS Belkin "router".



A mom-and-pop with said Belkin router who ties to source its /29 or 
dynamic /32 from ISP A out ISP B isn't going to get very far with it. 
The COTS "router" isn't going to NAT the traffic out the wrong interface 
in the first place.


In any case, ISP B will never see the return traffic. The rest of the 
Net isn't going to accept its /29 and /32 random advertisements, period.


--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: Request for comment -- BCP38

[Stephen Satchell]

On 10/01/2016 06:39 PM, Jay R. Ashworth wrote:

You *can* do BCP38 egress filtering on your network, but that filter
would *be in control of the Bad Guys* whom we're trying to kill off.


I don't see how you arrive at this conclusion.  For an aggregating 
router, the Bad Guys(tm) don't get anywhere near the control plane of 
the thing.  Besides, my security training (such as it is) demands that 
one implement defence in depth.  Specifically, if the Bad Guys(tm) find 
a way around my ingress filtering, the egress filtering will bump 'em off.


Where egress filtering really makes sense is with tunnels over SSH.  I 
haven't found where I can "hook into" a SSH tunnel with Linux.  I can 
turn off shell (and do), but the inbound packets look like local 
origination to the NetFilter.  And (at this early time) The Rules(sm) 
say that you always ACCEPT packets to and from "lo".  I've learned from 
hard experience that violating that rule breaks a lot of stuff.


Then there is the web server case.  The Bad Guys(tm) have access to PHP, 
or Perl, or even a user-level shell, but again NO ACCESS TO THE CONTROL 
PLANE.  Do we really want web-generated packets to get a bye?


(I want to put BGP egress filters on my mail servers, my FTP servers, my 
time servers, my *anything* servers.  It's easy, and it means the 
defence gets as close to the source as I can get it.)



The filtering needs to be on the other side of the administrative
span of control fence.


No reason NOT to have filtering on BOTH sides of that fence...

Re: Request for comment -- BCP38

[Florian Weimer]

* Jay R. Ashworth:

> - Original Message -
>> From: "Florian Weimer" 
>
>> * Jason Iannone:
>
>>> Are urpf and bcp38 interchangeable terms in this discussion?  It seems
>>> impractical and operationally risky to implement two unique ways to dos
>>> customers.  What are the lessons learned by operators doing static output
>>> filters, strict urpf, or loose/feasible urpf?
>> 
>> Historically (in 1998, when RFC 2267 was released), BCP 38 was an
>> egress filter applied at the AS boundary.
>
> You meant ingress, no?

It's a bit murky.  Section 4 suggests that it's not possible to apply
ingress filters on dialup access concnetrators.

> The control of the address space allocation resides with the upstream,
> as must control of the filtering.

That's not really true for customers who maintain their own routes and
IP assignments/allocations.

> You *can* do BCP38 egress filtering on your network, but that filter
> would *be in control of the Bad Guys* whom we're trying to kill off.

If you can't do ingress filtering (e.g. you do not give customers
dedicated physical ports, or the equipment does not allow tying ports
to specific IP addresses), egress filtering is surely better than
nothing at all.

In theory, it would not matter because the other side should have a
matching ingress filter.  In practice, egress filtering would make a
significant difference in traceability of attacks.  Any additional
filtering would do so.

Again, the goal should not be to deploy specific techonology in a
certain way, but to reduce spoofing and attacks which cannot be traced
back to the packet sources.

Re: Request for comment -- BCP38

[Octavio Alvarez]

On 09/26/2016 08:47 AM, Laszlo Hanyecz 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.  There is no automated or
>> scalable way for ISP A to distinguish this "legitimate" use from
>> spoofing; unless you consider it scalable for ISP A to maintain
>> thousands if not more "exception" ACLs to uRPF and BCP38 egress
>> filters to cover all of the cases of customers X, Y, and Z sourcing
>> traffic into ISP A's network using IPs allocated to them by other ISPs?
>>
> 
> This is a legitimate and interesting use case that is broken by BCP38. 
> The effectiveness of BCP38 at reducing abuse is dubious, but the
> benefits of asymmetric routing are well understood.  Why should everyone
> have to go out of their way to break this.. it works fine if you just
> don't mess with it.

This is really wrong.

Any ISP reserves the right to drop irrelevant traffic, traffic that does
not belong to its network (read: dropping traffic that is not required
to fulfill or is preventing the fulfillment of its contractual and
technical requirements).

BCP38 does not get in the way of the above and provides some potential
benefits like avoiding blacklists in some cases, detecting attacks and
hacked computers and contributing to the greater good of the community
(yes, some ISPs choose to be good netizens as much as possible, and this
is good).

This means that applying BCP38 is just natural for those that wish to
adopt it. Furthermore, being against it means being against the right to
drop irrelevant traffic.

In turn, this means that whenever a technical problem comes in conflict
with BCP38, it is just a sign that there is some underlying technical
flaw in the global Internet structure that should be addressed. I see
this as a feature of BCP38.

BCP38 does not break anything that it is not already broken, like the
PD-addressing multihoming problem. The problem is not BCP38.

Octavio.

Re: Request for comment -- BCP38

[Jay R. Ashworth]

- Original Message -
> From: "Florian Weimer" 

> * Jason Iannone:

>> Are urpf and bcp38 interchangeable terms in this discussion?  It seems
>> impractical and operationally risky to implement two unique ways to dos
>> customers.  What are the lessons learned by operators doing static output
>> filters, strict urpf, or loose/feasible urpf?
> 
> Historically (in 1998, when RFC 2267 was released), BCP 38 was an
> egress filter applied at the AS boundary.

You meant ingress, no?

The control of the address space allocation resides with the upstream,
as must control of the filtering.

You *can* do BCP38 egress filtering on your network, but that filter
would *be in control of the Bad Guys* whom we're trying to kill off.

The filtering needs to be on the other side of the administrative
span of control fence.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Request for comment -- BCP38

[Jay R. Ashworth]

- Original Message -
> From: "Hugo Slabbert" 

> 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.

I heartily encourage people to add content to the wiki for network types that
I'm insufficiently familiar with; cookbook entries are where I'd like to see
it end up.

If anyone wants to contribute please poke me or Alain for an account (keeping
a MediaWiki despammed is a fulltime job these days, if you allow user created
accounts, so we don't).  The address to poke at is moderator (at) bcp38.info

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Request for comment -- BCP38

[Jay R. Ashworth]

- Original Message -
> From: "John Levine" 

>>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.  There is no automated or scalable way for
>>ISP A to distinguish this "legitimate" use from spoofing; unless you
>>consider it scalable for ISP A to maintain thousands if not more
>>"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases
>>of customers X, Y, and Z sourcing traffic into ISP A's network using IPs
>>allocated to them by other ISPs?
> 
> I gather the usual customer response to this is "if you don't want our
> $50K/mo, I'm sure we can find another ISP who does."

Come on, John.  Anyone spending 50K a month belongs in PI space with BGP,
and they're a big enough customer for the ISPs to both put exception rules
in their ingress filters even if they're not.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Request for comment -- BCP38

[Jay R. Ashworth]

- Original Message -
> From: "Laszlo Hanyecz" 

>> 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.  There is no automated or
>> scalable way for ISP A to distinguish this "legitimate" use from
>> spoofing; unless you consider it scalable for ISP A to maintain
>> thousands if not more "exception" ACLs to uRPF and BCP38 egress
>> filters to cover all of the cases of customers X, Y, and Z sourcing
>> traffic into ISP A's network using IPs allocated to them by other ISPs?
> 
> This is a legitimate and interesting use case that is broken by BCP38.
> The effectiveness of BCP38 at reducing abuse is dubious, but the
> benefits of asymmetric routing are well understood.  Why should everyone
> have to go out of their way to break this.. it works fine if you just
> don't mess with it.

Let me see if I have your argument straight:

In order to enable an "interesting" use case that is used by maybe well under 
1% of end nodes not in PI address space, we should decide *not* to do 
something which makes it much easier to protect attack targets against
well over 75% of incoming attacks of ridiculous (>OC-12) bandwidth?

Is that what you're advocating?

No.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Request for comment -- BCP38

[Florian Weimer]

* Stephen Satchell:

> Given a single local inside network with:
>   * multiple uplink providers (typical multi-home situation)
>   * multiple edge routers, each connected to an upstream via a public
> routeable /30, and each further connected to the downstream inside
> network
>   * 50 subnets (to pick a number) of routeable IP address space
> downstream from the edge routers, with routing announcements to the
> world that direct packets back to the edge routers
>
> BCP38 demands that ANY packet leaving ANY edge router to the upstream
> MUST have a source address:
>   * within the 50 inside public route-able subnets, or
>   * within a list of "my" addresses in the public /30 subnets.
>
> True statement?

This depends on the agreements with the upstream providers.  They
might reasonably exclude their own /30 they provided to you and the
/30s from the other providers.

In general, packets from the /30s would not travel far anyway because
they would wail source address verification checks at the upstream
provider.  Some providers also use globally unique, but unrouted
addresses for transfer networks, for infrastructure protection
purposes.

Re: Request for comment -- BCP38

[Florian Weimer]

* Jason Iannone:

> I have a question regarding language. We've seen bcp38 described as a
> forwarding filter, preventing unallocated sources from leaving the AS.  I
> understand that unicast reverse path forwarding checks support bcp38, but
> urpf is an input check with significant technical differences from output
> filters.
>
> Are urpf and bcp38 interchangeable terms in this discussion?  It seems
> impractical and operationally risky to implement two unique ways to dos
> customers.  What are the lessons learned by operators doing static output
> filters, strict urpf, or loose/feasible urpf?

Historically (in 1998, when RFC 2267 was released), BCP 38 was an
egress filter applied at the AS boundary.  A complainant would be able
to identify the AS by looking at the IP address and contact the
relevant ISP.  Within the AS, that ISP could identify the actual
packet source by other means.

Reverse-path forwarding checks were explicitly ruled out as likely
infeasible even in RFC 2267, except for links which are essentially
dialups.

Current terminology is more complicated.  Personally, I think that
mandating specific approaches such as BCP 38 or uRPF does not work.
The goal should be to cut down spoofed traffic.  Whether this is done
by contracts (which are adhered to, obviously), monitoring or
immediate technical enforcement in the routers, does not matter at all.

> For a new implementation, I assume the safe bet is to start with loose
> urpf.  Even if it stops only some traffic it at least gives the network to
> dip its toes and expose some customer brokenness.

If loose uRPF is effective at all depends a lot on network architecture.

Re: Request for comment -- BCP38

[Stephen Satchell]

I'm trying to come up with a simple picture that embraces all the 
comments I've seen thus far on the definition of BCP38.  The example 
scenario I'm about to paint may be over-simplified -- but I like to 
start simple.


Given a single local inside network with:
  * multiple uplink providers (typical multi-home situation)
  * multiple edge routers, each connected to an upstream via a public 
routeable /30, and each further connected to the downstream inside network
  * 50 subnets (to pick a number) of routeable IP address space 
downstream from the edge routers, with routing announcements to the 
world that direct packets back to the edge routers


BCP38 demands that ANY packet leaving ANY edge router to the upstream 
MUST have a source address:

  * within the 50 inside public route-able subnets, or
  * within a list of "my" addresses in the public /30 subnets.

True statement?

What am I missing here?

(In this simplified view, I'm divorcing the BCP38 aspects from the 
practical effects of any policy or input filtering done by the 
upstreams, as I think that's a separate discussion -- important but 
off-topic right now for my understanding of BCP38 at its core.  Those 
practical aspects can be added later, AFTER describing the basics.)

Re: Request for comment -- BCP38

[Jason Iannone]

I have a question regarding language. We've seen bcp38 described as a
forwarding filter, preventing unallocated sources from leaving the AS.  I
understand that unicast reverse path forwarding checks support bcp38, but
urpf is an input check with significant technical differences from output
filters.

Are urpf and bcp38 interchangeable terms in this discussion?  It seems
impractical and operationally risky to implement two unique ways to dos
customers.  What are the lessons learned by operators doing static output
filters, strict urpf, or loose/feasible urpf?

For a new implementation, I assume the safe bet is to start with loose
urpf.  Even if it stops only some traffic it at least gives the network to
dip its toes and expose some customer brokenness.

Bcp38
>From my allocation accept, else deny

Urpf loose
>From route table exist accept, else deny

Urpf strict
>From next hop interface true accept, else deny

On Sep 27, 2016 4:52 AM, "Florian Weimer"  wrote:

> * Baldur Norddahl:
>
> > This means we can receive some packet on transit port A and then route
> out
> >>> a ICMP response on port B using the interface address from port A. But
> >>> transit B filters this ICMP packet because it has a source address
> >>> belonging to transit A.
> >> Interesting.  But this looks like a feature request for the router
> >> vendor, and not like an issue with BCP 38 filtering as such.
> >
> > Can you quote an RFC for anything that the router is doing wrong? Is
> > there a requirement that a router must support source routing?
>
> It's not an RFC conformance issue (several implementations of source
> address selection are possible).  But it appears to make it rather
> difficult to configure it in such a way it does what you need, and it
> looks like a reasonable enhancement request.
>
> > In our case we actually did contact the vendor. Turns out that it will
> > do source routing but not for packets from the control plane. There is
> > no way to resolve the issue with the current software available to
> > us. The vendor is not priotizing fixing this as I am also unable to
> > point to any RFC that is being violated.
>
> Source routing is not required to fix this.  Other options are using a
> globally routed IP address for the source address (this can also be
> used to conserve address space because the interface addresses will
> not matter anymore), or chosing the interface address based on the
> outgoing interface.
>

Re: Request for comment -- BCP38

[Florian Weimer]

* Baldur Norddahl:

> This means we can receive some packet on transit port A and then route out
>>> a ICMP response on port B using the interface address from port A. But
>>> transit B filters this ICMP packet because it has a source address
>>> belonging to transit A.
>> Interesting.  But this looks like a feature request for the router
>> vendor, and not like an issue with BCP 38 filtering as such.
>
> Can you quote an RFC for anything that the router is doing wrong? Is
> there a requirement that a router must support source routing?

It's not an RFC conformance issue (several implementations of source
address selection are possible).  But it appears to make it rather
difficult to configure it in such a way it does what you need, and it
looks like a reasonable enhancement request.

> In our case we actually did contact the vendor. Turns out that it will
> do source routing but not for packets from the control plane. There is
> no way to resolve the issue with the current software available to
> us. The vendor is not priotizing fixing this as I am also unable to
> point to any RFC that is being violated.

Source routing is not required to fix this.  Other options are using a
globally routed IP address for the source address (this can also be
used to conserve address space because the interface addresses will
not matter anymore), or chosing the interface address based on the
outgoing interface.

Re: Request for comment -- BCP38

[Hugo Slabbert]

ms either Mark's or John's suggestions could be potential solutions 
here?


--
Hugo Slabbert   | email, xmpp/jabber: h...@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 <ma...@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-bfb4ae589...@cisco.com>, Eliot Lear writes:

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN
From: Eliot Lear <l...@cisco.com>
To: Laszlo Hanyecz <las...@heliacal.net>, nanog@nanog.org
Message-ID: <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589...@cisco.com>
Subject: Re: Request for comment -- BCP38
References: <20160926180355.1229.qm...@ary.lan>
 <dc13dbd3-051c-2239-1ecb-3f4ab43b0...@heliacal.net>
In-Reply-To: <dc13dbd3-051c-2239-1ecb-3f4ab43b0...@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: ma...@isc.org


signature.asc
Description: PGP signature

Re: Request for comment -- BCP38

[Mark Andrews]

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-bfb4ae589...@cisco.com>, Eliot Lear writes:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --dWOXeq1OLTVjQNjObs7KPBUAPtMRfKIWN
> From: Eliot Lear <l...@cisco.com>
> To: Laszlo Hanyecz <las...@heliacal.net>, nanog@nanog.org
> Message-ID: <b6c3cf8f-7e41-fd98-3ba1-bfb4ae589...@cisco.com>
> Subject: Re: Request for comment -- BCP38
> References: <20160926180355.1229.qm...@ary.lan>
>  <dc13dbd3-051c-2239-1ecb-3f4ab43b0...@heliacal.net>
> In-Reply-To: <dc13dbd3-051c-2239-1ecb-3f4ab43b0...@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: ma...@isc.org

Re: Request for comment -- BCP38

[Eliot Lear]

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 BCP38.
>>> 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. 
>> 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.  
> 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
>>
>
>




signature.asc
Description: OpenPGP digital signature

Re: Request for comment -- BCP38

[Baldur Norddahl]

This means we can receive some packet on transit port A and then route out

a ICMP response on port B using the interface address from port A. But
transit B filters this ICMP packet because it has a source address
belonging to transit A.

Interesting.  But this looks like a feature request for the router
vendor, and not like an issue with BCP 38 filtering as such.


Can you quote an RFC for anything that the router is doing wrong? Is 
there a requirement that a router must support source routing?


In our case we actually did contact the vendor. Turns out that it will 
do source routing but not for packets from the control plane. There is 
no way to resolve the issue with the current software available to us. 
The vendor is not priotizing fixing this as I am also unable to point to 
any RFC that is being violated.


Even if or when we get a fix, this will continue to be a problem because 
it is a very common setup. There are thousands of networks out there 
that have the issue and many of them are probably not even realising it.





 From this follows that BCP38 can break things like traceroute and path MTU
discovery in what is a very common setup.

That doesn't follow.  In order to break PMTUD, you also need an MTU
drop.  Is that a common configuration for routers in points in the
network where this would matter?
It is not a common configuration which was what I said in the text you 
removed from that quote:


"From this follows that BCP38 can break things like traceroute and path 
MTU discovery in what is a very common setup. The only reason we do not 
have a bigger problem is that few networks will have a downward MTU 
change at this point in the network".


Besides it appears that path MTU is broken in general.

We accept the problem because the only actual consequence is that 
traceroute is a little funky.


Regards,

Baldur

Re: Request for comment -- BCP38

[Florian Weimer]

* Baldur Norddahl:

> Den 26. sep. 2016 18.02 skrev "Mike Hammett" :
>>
>> The only asymmetric routing broken is when the source isn't in public
> Internet route-able space. That just leaves those multi-ISP WAN routers
> that NAT it.
>
> Some of our IP transits implement filtering. All of our transits assigned
> /30 subnets on the transit ports from their own range (the alternate would
> have be to ask us to supply the /30 from our pool).
>
> Our provider edge router will send back ICMP packets using the interface
> address from the interface that received the original packet. It will then
> route the packet using our normal routing table.
>
> This means we can receive some packet on transit port A and then route out
> a ICMP response on port B using the interface address from port A. But
> transit B filters this ICMP packet because it has a source address
> belonging to transit A.

Interesting.  But this looks like a feature request for the router
vendor, and not like an issue with BCP 38 filtering as such.

> From this follows that BCP38 can break things like traceroute and path MTU
> discovery in what is a very common setup.

That doesn't follow.  In order to break PMTUD, you also need an MTU
drop.  Is that a common configuration for routers in points in the
network where this would matter?

Re: Request for comment -- BCP38

[Baldur Norddahl]

Den 26. sep. 2016 18.02 skrev "Mike Hammett" :
>
> The only asymmetric routing broken is when the source isn't in public
Internet route-able space. That just leaves those multi-ISP WAN routers
that NAT it.

Some of our IP transits implement filtering. All of our transits assigned
/30 subnets on the transit ports from their own range (the alternate would
have be to ask us to supply the /30 from our pool).

Our provider edge router will send back ICMP packets using the interface
address from the interface that received the original packet. It will then
route the packet using our normal routing table.

This means we can receive some packet on transit port A and then route out
a ICMP response on port B using the interface address from port A. But
transit B filters this ICMP packet because it has a source address
belonging to transit A.

>From this follows that BCP38 can break things like traceroute and path MTU
discovery in what is a very common setup. The only reason we do not have a
bigger problem is that few networks will have a downward MTU change at this
point in the network.

Regards

Baldur

Re: Request for comment -- BCP38

[Laszlo Hanyecz]

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 BCP38.

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.  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.   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

Re: Request for comment -- BCP38

[John Levine]

>>>
>>> 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 BCP38.
>
>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.  Letters 
matter.

R's,
John

Re: Request for comment -- BCP38

[Hugo Slabbert]

On Mon 2016-Sep-26 12:39:21 -0400, John R. Levine  wrote:

If we're talking about networks with that kind of MRC, is it really 
that far of a stretch to require PI space for this?  Then again:  
If we're talking about that kind of MRC, then I'm assuming ISP A 
can be coaxed to allow explicit and well-defined exceptions on the 
customer's links.


Yes.

A) Check the prices for PI space, if you can even get any.

B) Our network works fine with PA space.  If you claim otherwise, we 
know plenty of other operators who aren't as wedged as you are.


Trying to solve technical problems with social solutions rarely 
works. See for example, the sad history of passwords.


Mike and Aled covering this better than I am.



Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Request for comment -- BCP38

[John R. Levine]

If we're talking about networks with that kind of MRC, is it really that far 
of a stretch to require PI space for this?  Then again:  If we're talking 
about that kind of MRC, then I'm assuming ISP A can be coaxed to allow 
explicit and well-defined exceptions on the customer's links.


Yes.

A) Check the prices for PI space, if you can even get any.

B) Our network works fine with PA space.  If you claim otherwise, we know 
plenty of other operators who aren't as wedged as you are.


Trying to solve technical problems with social solutions rarely works. 
See for example, the sad history of passwords.



Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Request for comment -- BCP38

[Hugo Slabbert]

On Mon 2016-Sep-26 12:25:58 -0400, John R. Levine  wrote:


I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."


I myself am talking about the latter and included the option of PI 
space to cover that (although I guess at some point this can be 
made fly with PA space from another provider if both providers are 
willing enough to play ball), though from the $50/mo figure John 
listed, I'm assuming he's talking about the latter.


Who said $50/mo?


Apparently I need even more caffeine that I first imagined...

If we're talking about networks with that kind of MRC, is it really that 
far of a stretch to require PI space for this?  Then again:  If we're 
talking about that kind of MRC, then I'm assuming ISP A can be coaxed to 
allow explicit and well-defined exceptions on the customer's links.


This discussion started wrt to COTS dual-ISP routers though, as mentioned 
in Ken Chase's message, no?  Where I'm assuming we're talking about 
mom-and-pop operations rather than a $50K/mo business account.




Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Request for comment -- BCP38

[Mike Hammett]

I would assume that on a broadband grade connection it shouldn't work unless 
you have a niche player and proper LOA. 

I would assume that on a BGP level circuit that it would work, again, given 
proper documentation (LOAs, IRRDB entry, etc.). IRRDBs make this wonderfully 
easier. By default, deny. Allow whatever is in the IRRDB entry. $250 for manual 
changes. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Hugo Slabbert" <h...@slabnet.com> 
To: "Mike Hammett" <na...@ics-il.net> 
Cc: "John Levine" <jo...@iecc.com>, nanog@nanog.org 
Sent: Monday, September 26, 2016 11:21:55 AM 
Subject: Re: Request for comment -- BCP38 


On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <na...@ics-il.net> wrote: 

>> 
>>- Original Message - 
>> 
>>From: "John Levine" <jo...@iecc.com> 
>>To: nanog@nanog.org 
>>Sent: Monday, September 26, 2016 11:04:33 AM 
>>Subject: Re: Request for comment -- BCP38 
>> 
>>>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. There is no automated or scalable way for 
>>>ISP A to distinguish this "legitimate" use from spoofing; unless you 
>>>consider it scalable for ISP A to maintain thousands if not more 
>>>"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases 
>>>of customers X, Y, and Z sourcing traffic into ISP A's network using IPs 
>>>allocated to them by other ISPs? 
>> 
>>I gather the usual customer response to this is "if you don't want our 
>>$50K/mo, I'm sure we can find another ISP who does." 
>> 
>>From the conversations I've had with ISPs, the inability to manage 
>>legitimate traffic from dual homed customer networks is the most 
>>significant bar to widespread BCP38. 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. 
>> 
>>R's, 
>>John 
>> 
>>PS: "Illegitimate" is not a synonym for inconvenient, or hard to handle. 
>> 

>Are you talking BGP level customers or individual small businesses' 
>broadband service? 

I myself am talking about the latter and included the option of PI space to 
cover that (although I guess at some point this can be made fly with PA 
space from another provider if both providers are willing enough to play 
ball), though from the $50/mo figure John listed, I'm assuming he's talking 
about the latter. 

Do people really expect to be able to do this on residential or small 
business broadband networks? I can't remember any time in recent memory 
where I assumed I could set a source address to any IP I fancy and have 
that packet successfully make its way through the SP's network. 

> 
>- 
>Mike Hammett 
>Intelligent Computing Solutions 
>http://www.ics-il.com 
> 
>Midwest-IX 
>http://www.midwest-ix.com 

-- 
Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com 
pgp key: B178313E | also on Signal 

Re: Request for comment -- BCP38

[Aled Morris]

On 26 September 2016 at 16:47, Laszlo Hanyecz  wrote:

>
> On 2016-09-26 15:12, Hugo Slabbert 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 BCP38.



I don't agree that this is legitimate.

Also we're talking about typical mom & pop home users here.

I'll sell you a multihoming capable service at a price that includes my
time in maintaining your bespoke configuration, but my off-the-shelf
home-user service is going to be BCP38.

Aled

Re: Request for comment -- BCP38

[Hugo Slabbert]

On Mon 2016-Sep-26 09:21:55 -0700, Hugo Slabbert <h...@slabnet.com> wrote:



On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <na...@ics-il.net> wrote:



- Original Message -

From: "John Levine" <jo...@iecc.com>
To: nanog@nanog.org
Sent: Monday, September 26, 2016 11:04:33 AM
Subject: Re: Request for comment -- BCP38


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. There is no automated or scalable way for
ISP A to distinguish this "legitimate" use from spoofing; unless you
consider it scalable for ISP A to maintain thousands if not more
"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases
of customers X, Y, and Z sourcing traffic into ISP A's network using IPs
allocated to them by other ISPs?


I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."

From the conversations I've had with ISPs, the inability to manage
legitimate traffic from dual homed customer networks is the most
significant bar to widespread BCP38. 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.

R's,
John

PS: "Illegitimate" is not a synonym for inconvenient, or hard to handle.



Are you talking BGP level customers or individual small businesses' 
broadband service?


I myself am talking about the latter... 


...dammit...obviously "former" here, not "latter".  Caffeine injection 
requisitioned.


...and included the option of PI space to cover that (although I guess at 
some point this can be made fly with PA space from another provider if 
both providers are willing enough to play ball), though from the $50/mo 
figure John listed, I'm assuming he's talking about the latter.


Do people really expect to be able to do this on residential or small 
business broadband networks?  I can't remember any time in recent 
memory where I assumed I could set a source address to any IP I fancy 
and have that packet successfully make its way through the SP's 
network.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal




signature.asc
Description: Digital signature

Re: Request for comment -- BCP38

[Hugo Slabbert]

On Mon 2016-Sep-26 11:15:11 -0500, Mike Hammett <na...@ics-il.net> wrote:



- Original Message -

From: "John Levine" <jo...@iecc.com>
To: nanog@nanog.org
Sent: Monday, September 26, 2016 11:04:33 AM
Subject: Re: Request for comment -- BCP38


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. There is no automated or scalable way for
ISP A to distinguish this "legitimate" use from spoofing; unless you
consider it scalable for ISP A to maintain thousands if not more
"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases
of customers X, Y, and Z sourcing traffic into ISP A's network using IPs
allocated to them by other ISPs?


I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."

From the conversations I've had with ISPs, the inability to manage
legitimate traffic from dual homed customer networks is the most
significant bar to widespread BCP38. 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.

R's,
John

PS: "Illegitimate" is not a synonym for inconvenient, or hard to handle.



Are you talking BGP level customers or individual small businesses' 
broadband service?


I myself am talking about the latter and included the option of PI space to 
cover that (although I guess at some point this can be made fly with PA 
space from another provider if both providers are willing enough to play 
ball), though from the $50/mo figure John listed, I'm assuming he's talking 
about the latter.


Do people really expect to be able to do this on residential or small 
business broadband networks?  I can't remember any time in recent memory 
where I assumed I could set a source address to any IP I fancy and have 
that packet successfully make its way through the SP's network.




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Request for comment -- BCP38

[Mike Hammett]

Are you talking BGP level customers or individual small businesses' broadband 
service? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "John Levine" <jo...@iecc.com> 
To: nanog@nanog.org 
Sent: Monday, September 26, 2016 11:04:33 AM 
Subject: Re: Request for comment -- BCP38 

>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. There is no automated or scalable way for 
>ISP A to distinguish this "legitimate" use from spoofing; unless you 
>consider it scalable for ISP A to maintain thousands if not more 
>"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases 
>of customers X, Y, and Z sourcing traffic into ISP A's network using IPs 
>allocated to them by other ISPs? 

I gather the usual customer response to this is "if you don't want our 
$50K/mo, I'm sure we can find another ISP who does." 

>From the conversations I've had with ISPs, the inability to manage 
legitimate traffic from dual homed customer networks is the most 
significant bar to widespread BCP38. 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. 

R's, 
John 

PS: "Illegitimate" is not a synonym for inconvenient, or hard to handle. 

Re: Request for comment -- BCP38

[John Levine]

>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.  There is no automated or scalable way for 
>ISP A to distinguish this "legitimate" use from spoofing; unless you 
>consider it scalable for ISP A to maintain thousands if not more 
>"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases 
>of customers X, Y, and Z sourcing traffic into ISP A's network using IPs 
>allocated to them by other ISPs?

I gather the usual customer response to this is "if you don't want our
$50K/mo, I'm sure we can find another ISP who does."

>From the conversations I've had with ISPs, the inability to manage
legitimate traffic from dual homed customer networks is the most
significant bar to widespread BCP38.  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.

R's,
John

PS: "Illegitimate" is not a synonym for inconvenient, or hard to handle.

Re: Request for comment -- BCP38

[Seth Mattinen]

On 9/26/16 07:47, Stephen Satchell wrote:

On 09/26/2016 07:11 AM, Paul Ferguson wrote:

No -- BCP38 only prescribes filtering outbound to ensure that no
packets leave your network with IP source addresses which are not
from within your legitimate allocation.


So, to beat that horse to a fare-thee-well, to be BCP38 compliant I
need, on every interface sending packets out to the internet, to block
any source address matching a subnet in the BOGON list OR not matching
any of my routeable network subnets?  Plus add null-route entries for
all the BOGONs in my routing table so I don't send a bad destination
packet to my upstream?




I start with customer interfaces and configure them to only allow 
traffic with a source address in their assigned subnet.


~Seth

Re: Request for comment -- BCP38

[Mike Hammett]

The only asymmetric routing broken is when the source isn't in public Internet 
route-able space. That just leaves those multi-ISP WAN routers that NAT it. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Laszlo Hanyecz" <las...@heliacal.net> 
To: nanog@nanog.org 
Sent: Monday, September 26, 2016 10:47:43 AM 
Subject: Re: Request for comment -- BCP38 


On 2016-09-26 15:12, Hugo Slabbert wrote: 
> 
> On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase <m...@sizone.org> wrote: 
> 
>> This might break some of those badly-behaving "dual ISP" COTS routers 
>> out there 
>> that use different inbound from outbound paths since each is the 
>> fastest of 
>> either link. 
> 
> As it should. 
> 
> 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. There is no automated or 
> scalable way for ISP A to distinguish this "legitimate" use from 
> spoofing; unless you consider it scalable for ISP A to maintain 
> thousands if not more "exception" ACLs to uRPF and BCP38 egress 
> filters to cover all of the cases of customers X, Y, and Z sourcing 
> traffic into ISP A's network using IPs allocated to them by other ISPs? 
> 

This is a legitimate and interesting use case that is broken by BCP38. 
The effectiveness of BCP38 at reducing abuse is dubious, but the 
benefits of asymmetric routing are well understood. Why should everyone 
have to go out of their way to break this.. it works fine if you just 
don't mess with it. 

> If you want to play asymmetry tricks, get some PI space and make 
> arrangements. If that's outside your wheelhouse, get an ISP that will 
> sell this to you as a service either with dissimilar links they 
> provide to you or over-the-top with tunnels etc. 
> 
> Playing NAT games with different classes of traffic to e.g. send 
> traffic type 1 over ISP A and traffic type 2 over ISP B *BUT* using 
> the corresponding source addresses in each case and having the traffic 
> return back over the same links is fine and dandy. If you send 
> traffic into an ISP-provided link using addresses from another 
> provider, though, that ISP *should* be dropping that traffic. If they 
> don't, send them here so we can yell at them. 
> 

So instead of being able to use simple destination based routes to 
direct their traffic, like the service provider can, the CPE operator 
has to learn and implement policy based routing and manage state to 
juggle each of the IP addresses they are assigned. It's orders of 
magnitude harder to do this with the current ecosystem of routers/CPEs, 
than it is to add a destination route. I think stuff like this is one 
of the reasons why many are hesitant to implement this type of 
filtering. It makes a specific type of abuse easier to track down *for 
someone else* but it doesn't help you much and it can cause debugging 
nightmares when something doesn't work due to filtering. 

-Laszlo 

>> I did this manually when I was messing around with multiple broadband 
>> links on 
>> a fbsd router years ago, was glad it worked at the time. 
>> 
>> /kc 
>> 
>> 
>> On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said: 
>> >No -- BCP38 only prescribes filtering outbound to ensure that no 
>> packets leave your network with IP source addresses which are not 
>> from within your legitimate allocation. 
>> > 
>> > - ferg 
>> > 
>> > 
>> >On September 26, 2016 7:05:49 AM PDT, Stephen Satchell 
>> <l...@satchell.net> wrote: 
>> >>Is this an accurate thumbnail summary of BCP38 (ignoring for the 
>> moment 
>> >> 
>> >>the issues of multi-home), or is there something I missed? 
>> >> 
>> >>> The basic philosophy of BCP38 boils down to two axioms: 
>> >>> 
>> >>> Don't let the "bad stuff" into your router 
>> >>> Don't let the "bad stuff" leave your router 
>> >>> 
>> >>> The original definition of "bad stuff" is limited to source- 
>> >>> address grooming both inbound and outbound. I've expanded on 
>> the 
>> >>> original definition by including rule generation to control 
>> >>> broadcast address abuse. 
>> > 
>> >-- 
>> >Sent from my Android device with K-9 Mail. Please excuse my brevity. 
>> 
>> -- 
>> Ken Chase - m...@sizone.org Toronto Canada 
> 

Re: Request for comment -- BCP38

[Laszlo Hanyecz]

On 2016-09-26 15:12, Hugo Slabbert wrote:


On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase  wrote:

This might break some of those badly-behaving "dual ISP" COTS routers 
out there
that use different inbound from outbound paths since each is the 
fastest of

either link.


As it should.

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.  There is no automated or 
scalable way for ISP A to distinguish this "legitimate" use from 
spoofing; unless you consider it scalable for ISP A to maintain 
thousands if not more "exception" ACLs to uRPF and BCP38 egress 
filters to cover all of the cases of customers X, Y, and Z sourcing 
traffic into ISP A's network using IPs allocated to them by other ISPs?




This is a legitimate and interesting use case that is broken by BCP38.  
The effectiveness of BCP38 at reducing abuse is dubious, but the 
benefits of asymmetric routing are well understood.  Why should everyone 
have to go out of their way to break this.. it works fine if you just 
don't mess with it.


If you want to play asymmetry tricks, get some PI space and make 
arrangements.  If that's outside your wheelhouse, get an ISP that will 
sell this to you as a service either with dissimilar links they 
provide to you or over-the-top with tunnels etc.


Playing NAT games with different classes of traffic to e.g. send 
traffic type 1 over ISP A and traffic type 2 over ISP B *BUT* using 
the corresponding source addresses in each case and having the traffic 
return back over the same links is fine and dandy.  If you send 
traffic into an ISP-provided link using addresses from another 
provider, though, that ISP *should* be dropping that traffic.  If they 
don't, send them here so we can yell at them.




So instead of being able to use simple destination based routes to 
direct their traffic, like the service provider can, the CPE operator 
has to learn and implement policy based routing and manage state to 
juggle each of the IP addresses they are assigned.  It's orders of 
magnitude harder to do this with the current ecosystem of routers/CPEs, 
than it is to add a destination route.  I think stuff like this is one 
of the reasons why many are hesitant to implement this type of 
filtering.  It makes a specific type of abuse easier to track down *for 
someone else* but it doesn't help you much and it can cause debugging 
nightmares when something doesn't work due to filtering.


-Laszlo

I did this manually when I was messing around with multiple broadband 
links on

a fbsd router years ago, was glad it worked at the time.

/kc


On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said:
 >No -- BCP38 only prescribes filtering outbound to ensure that no 
packets leave your network with IP source addresses which are not 
from within your legitimate allocation.

 >
 > - ferg
 >
 >
 >On September 26, 2016 7:05:49 AM PDT, Stephen Satchell 
 wrote:
 >>Is this an accurate thumbnail summary of BCP38 (ignoring for the 
moment

 >>
 >>the issues of multi-home), or is there something I missed?
 >>
 >>> The basic philosophy of BCP38 boils down to two axioms:
 >>>
 >>> Don't let the "bad stuff" into your router
 >>> Don't let the "bad stuff" leave your router
 >>>
 >>> The original definition of "bad stuff" is limited to source-
 >>> address grooming both inbound and outbound. I've expanded on 
the

 >>> original definition by including rule generation to control
 >>> broadcast address abuse.
 >
 >--
 >Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
Ken Chase - m...@sizone.org Toronto Canada

Re: Request for comment -- BCP38

[Hugo Slabbert]

On Mon 2016-Sep-26 10:47:24 -0400, Ken Chase  wrote:


This might break some of those badly-behaving "dual ISP" COTS routers out there
that use different inbound from outbound paths since each is the fastest of
either link.


As it should.

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.  There is no automated or scalable way for 
ISP A to distinguish this "legitimate" use from spoofing; unless you 
consider it scalable for ISP A to maintain thousands if not more 
"exception" ACLs to uRPF and BCP38 egress filters to cover all of the cases 
of customers X, Y, and Z sourcing traffic into ISP A's network using IPs 
allocated to them by other ISPs?


If you want to play asymmetry tricks, get some PI space and make 
arrangements.  If that's outside your wheelhouse, get an ISP that will sell 
this to you as a service either with dissimilar links they provide to you 
or over-the-top with tunnels etc.


Playing NAT games with different classes of traffic to e.g. send traffic 
type 1 over ISP A and traffic type 2 over ISP B *BUT* using the 
corresponding source addresses in each case and having the traffic return 
back over the same links is fine and dandy.  If you send traffic into an 
ISP-provided link using addresses from another provider, though, that ISP 
*should* be dropping that traffic.  If they don't, send them here so we can 
yell at them.



I did this manually when I was messing around with multiple broadband links on
a fbsd router years ago, was glad it worked at the time.

/kc


On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said:
 >No -- BCP38 only prescribes filtering outbound to ensure that no packets 
leave your network with IP source addresses which are not from within your 
legitimate allocation.
 >
 > - ferg
 >
 >
 >On September 26, 2016 7:05:49 AM PDT, Stephen Satchell  
wrote:
 >>Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
 >>
 >>the issues of multi-home), or is there something I missed?
 >>
 >>> The basic philosophy of BCP38 boils down to two axioms:
 >>>
 >>> Don't let the "bad stuff" into your router
 >>> Don't let the "bad stuff" leave your router
 >>>
 >>> The original definition of "bad stuff" is limited to source-
 >>> address grooming both inbound and outbound.  I've expanded on the
 >>> original definition by including rule generation to control
 >>> broadcast address abuse.
 >
 >--
 >Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
Ken Chase - m...@sizone.org Toronto Canada


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Request for comment -- BCP38

[Hugo Slabbert]

On Mon 2016-Sep-26 07:47:50 -0700, Stephen Satchell  wrote:


On 09/26/2016 07:11 AM, Paul Ferguson wrote:

No -- BCP38 only prescribes filtering outbound to ensure that no
packets leave your network with IP source addresses which are not
from within your legitimate allocation.


So, to beat that horse to a fare-thee-well, to be BCP38 compliant I 
need, on every interface sending packets out to the internet, to 
block any source address matching a subnet in the BOGON list OR not 
matching any of my routeable network subnets?  


TBF, I would assume that you don't have routable/allocated networks within 
BOGON ranges, so just "if src in mynets permit else discard" covers both 
sets.


Plus add null-route entries for all the BOGONs in my routing table so I 
don't send a bad destination packet to my upstream?


I don't think that falls within the purview of BCP38 as BCP38 has to do 
with source address filtering/verification rather than destination.  If 
you're running full tables and filtering BOGONs on BGP import, though, you 
shouldn't have routes for BOGONs in your tables and with a 0/0 discard 
should be dropping them anyway, but if you're not running full tables and 
so need to "punch holes" in a static default, then explicit null-routes for 
BOGON destinations would do it.  Honestly, though: your upstream probably 
drops BOGON destinations anyway, so dropping BOGON destinations within your 
own network is just (a) good hygiene and (b) saves from your transit bill 
however may bps of BOGON-destined traffic you have.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Request for comment -- BCP38

[Paul Ferguson]

> On Sep 26, 2016, at 7:47 AM, Stephen Satchell  wrote:
> 
> On 09/26/2016 07:11 AM, Paul Ferguson wrote:
>> No -- BCP38 only prescribes filtering outbound to ensure that no
>> packets leave your network with IP source addresses which are not
>> from within your legitimate allocation.
> 
> So, to beat that horse to a fare-thee-well, to be BCP38 compliant I need, on 
> every interface sending packets out to the internet, to block any source 
> address matching a subnet in the BOGON list OR not matching any of my 
> routeable network subnets?  Plus add null-route entries for all the BOGONs in 
> my routing table so I don't send a bad destination packet to my upstream?


BCP38 only provides for disallowing spoofed packets into the Internet. Any 
additional filtering against bosons, etc., are probably a good idea, just not 
including specifically in BCP38.

- ferg


—
Paul Ferguson
ICEBRG.io
Seattle, Washington, USA





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Request for comment -- BCP38

[Elmar K. Bins]

Re Stephen,

> So, to beat that horse to a fare-thee-well, to be BCP38 compliant I need, on
> every interface sending packets out to the internet, to block any source
> address matching a subnet in the BOGON list OR not matching any of my
> routeable network subnets?  Plus add null-route entries for all the BOGONs
> in my routing table so I don't send a bad destination packet to my upstream?

The correct way to implement this is
  - outgoing permit my allocated address blocks as source addresses
  - outgoing deny EVERYTHING (else)

Elmar.

Re: Request for comment -- BCP38

[Stephen Satchell]

On 09/26/2016 07:11 AM, Paul Ferguson wrote:

No -- BCP38 only prescribes filtering outbound to ensure that no
packets leave your network with IP source addresses which are not
from within your legitimate allocation.


So, to beat that horse to a fare-thee-well, to be BCP38 compliant I 
need, on every interface sending packets out to the internet, to block 
any source address matching a subnet in the BOGON list OR not matching 
any of my routeable network subnets?  Plus add null-route entries for 
all the BOGONs in my routing table so I don't send a bad destination 
packet to my upstream?

Re: Request for comment -- BCP38

[Ken Chase]

This might break some of those badly-behaving "dual ISP" COTS routers out there
that use different inbound from outbound paths since each is the fastest of
either link.

I did this manually when I was messing around with multiple broadband links on
a fbsd router years ago, was glad it worked at the time.

/kc


On Mon, Sep 26, 2016 at 07:11:42AM -0700, Paul Ferguson said:
  >No -- BCP38 only prescribes filtering outbound to ensure that no packets 
leave your network with IP source addresses which are not from within your 
legitimate allocation.
  >
  > - ferg 
  >
  >
  >On September 26, 2016 7:05:49 AM PDT, Stephen Satchell  
wrote:
  >>Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
  >>
  >>the issues of multi-home), or is there something I missed?
  >>
  >>> The basic philosophy of BCP38 boils down to two axioms:
  >>>
  >>> Don't let the "bad stuff" into your router
  >>> Don't let the "bad stuff" leave your router
  >>>
  >>> The original definition of "bad stuff" is limited to source-
  >>> address grooming both inbound and outbound.  I've expanded on the
  >>> original definition by including rule generation to control
  >>> broadcast address abuse.
  >
  >-- 
  >Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Ken Chase - m...@sizone.org Toronto Canada

Re: Request for comment -- BCP38

[Paul Ferguson]

No -- BCP38 only prescribes filtering outbound to ensure that no packets leave 
your network with IP source addresses which are not from within your legitimate 
allocation.

 - ferg 


On September 26, 2016 7:05:49 AM PDT, Stephen Satchell  
wrote:
>Is this an accurate thumbnail summary of BCP38 (ignoring for the moment
>
>the issues of multi-home), or is there something I missed?
>
>> The basic philosophy of BCP38 boils down to two axioms:
>>
>> Don't let the "bad stuff" into your router
>> Don't let the "bad stuff" leave your router
>>
>> The original definition of "bad stuff" is limited to source-
>> address grooming both inbound and outbound.  I've expanded on the
>> original definition by including rule generation to control
>> broadcast address abuse.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.