nanog mailing list archives
Re: BCP38 is hard, was TWC (AS11351) blocking all NTP?
From: Mark Andrews <marka () isc org>
Date: Wed, 05 Feb 2014 10:46:47 +1100
In message <52F17102.2000505 () alvarezp ods org>, Octavio Alvarez writes:
On 04/02/14 14:18, John Levine wrote:I was at a conference with people from some Very Large ISPs. They told me that many of their large customers absolutely will not let them do BCP38 filtering. ("If you don't want our business, we can find someone else who does.") The usual problem is that they have PA space from two providers and for various reasons, not all of which are stupid, traffic with provider A's addresses sometimes goes out through provider B. Adding to the excitement, some of these customers are medium sized ISPs with multihomed customers of their own.I haven't read it all, but section 3 says:However, by restricting transit traffic which originates from a downstream network to known, and intentionally advertised, prefix(es), the problem of source address spoofing can be virtually eliminated in this attack scenario.If ISP has customer A with multiple *known* valid networks --doesn't matter if ISP allocated them to customer or not-- and ISP lets them all out, but filters everything else, ISP is still complying with BCP 38. Here it's not a matter of blocking "just because". It's blocking unknown addresses. It doesn't either mean that ISP should not open the filters if a new prefix is requested by the customer.
Or downstream customers. SIDR provides provides the crypotographic glue that can be used to automate this. The end customer has a CERT which authenticates their use of the address. The second ISP supplies a CERT which the end customer signs saying they can source this range. Repeat until you reach a big enough ISP that you just have a agreement that no unverified traffic will injected down the link. These CERTS can then be used to build perfect input and output filters. Initially you may have to have manual inputs but with increasing use of SIDR the amount of manual intervention will drop. I.e. If you multi-home you need to have provable use of the address space. This isn't significantly different to the regular use of SIDR. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka () isc org
Current thread:
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP?, (continued)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? John R. Levine (Feb 04)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? William Herrin (Feb 04)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? John Levine (Feb 04)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? Mark Andrews (Feb 04)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? Randy Bush (Feb 04)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? Jay Ashworth (Feb 04)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? Saku Ytti (Feb 05)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? Jared Mauch (Feb 05)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? Saku Ytti (Feb 05)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? Octavio Alvarez (Feb 04)
- Re: BCP38 is hard, was TWC (AS11351) blocking all NTP? Mark Andrews (Feb 04)
- Re: TWC (AS11351) blocking all NTP? Damian Menscher (Feb 04)
- Re: TWC (AS11351) blocking all NTP? John R. Levine (Feb 03)
- Re: TWC (AS11351) blocking all NTP? Jared Mauch (Feb 03)
- Re: TWC (AS11351) blocking all NTP? John R. Levine (Feb 03)
- Re: TWC (AS11351) blocking all NTP? Joe Greco (Feb 03)
- Re: TWC (AS11351) blocking all NTP? Valdis . Kletnieks (Feb 03)
- Re: TWC (AS11351) blocking all NTP? Doug Barton (Feb 03)
- Re: TWC (AS11351) blocking all NTP? Majdi S. Abbas (Feb 03)
- Re: TWC (AS11351) blocking all NTP? Doug Barton (Feb 03)