[dns-operations] SAC004 & BCP38 [was: DNS deluge for x.p.ctrc.cc]

[Ejay Hire]

Disclaimer, I have not read the full source document.

I interpret this section to mean customers that are
Multihomed with reachability from multiple providers.  In
today's internet that means BGP, or coordinated with both
ISPs.

We had an incident where a customer was making a dial-up
connection to another ISP, and then used our upstream
bandwidth to send spam using the dial-up IP.  MCI (our
upstream) caught the "not-technically spoofed, but shouldn't
be on my network" traffic in their ingress filters (facing
us) and dropped the traffic.  The customer reported
reachability issues to us, we investigated, figured it out,
shut them down, and that's when we implemented customer
facing RPF checks.

-ejay

> -----Original Message-----
> From: dns-operations-bounces at lists.oarci.net 
> [mailto:dns-operations-bounces at lists.oarci.net] On Behalf
Of 
> Sam Norris
> Sent: Wednesday, March 01, 2006 6:15 PM
> To: dns-operations at mail.oarc.isc.org
> Subject: [dns-operations] SAC004 & BCP38 [was: DNS deluge
for 
> x.p.ctrc.cc]
> 
> I'm starting a new thread to talk specifically about the
subject.
> 
> * Paul Vixie wrote:
> > # > ... there is no valid reason to spoof so blocking
that 
> capability 
> > takes
> > # > nothing away from the internet.
> > #
> > # Unfortunly, that's not true. Spoofing is a common and
wide spread 
> > technique
> > # to simulate multihoming without PI space. This is 
> independant of an own 
> > AS.
> >
> > see [SAC004 5.1] 
> (http://www.icann.org/committees/security/sac004.txt).
> 
> I consider 'spoofing' the practice of forging your IP
header 
> to be someone 
> you are not.  This is a bit different than using your IP
space across 
> multiple providers, however I agree that in most instances
it 
> can be used to 
> describe both.
> 
> In SAC004 I read this:
> 
> 5.1. Multihomed networks who use address space from
multiple upstream
>    providers will occasionally emit packets into upstream
"A" 
> using source
>    addresses that were assigned by upstream "B".  In this 
> case, upstream
>    "A" must be prepared to accept source addresses in
address 
> space "B",
>    and vice versa.  This is only a slight complication and
does not
>    invalidate the approach.
> 
> I'm wondering if there are any proposed suggestions to the
slight 
> complication yet?  This is really the biggest stepping
stone that the 
> industry needs to take to implement this I believe.  There

> are many public 
> databases already in existance that store routing and ip 
> information - can 
> these feasably be used ?  ARIN knows my IP ranges, LEVEL3
has 
> a route object 
> and prefix filters, etc... Are there any resources out
there 
> on how to 
> accomplish BCP38 and keep your multihomed customers
flowing?  
> BCP38 was 
> written in 2000 and is not very popular I take it.  Can
this 
> be implemented 
> with current hardware and infrastructure today without 
> forcing everyone to 
> buy new routing equipment?
> 
> If this is the wrong place for this topic then tell me ...
This whole 
> recursive dns server issue is only 1 of the many that will

> start cropping up 
> and it would be nice to come up with a real solution (
alongside the 
> recursive dns issues at hand ).
> 
> Sam
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations
>