[c-nsp] DNS amplification

Mon Mar 18 12:53:51 UTC 2013

	
	I think BCP it is a solution. Perhaps not complete but hardy any single
solution would be suitable for a complex problem as this one.

	If you are the end-user organization with a multihomed topology you
apply BCP38 within your own scope. This will help to have less spoofed
traffic. Not solving all the problems but it would help not seeing your
spoofed packets all over the Internet.

	And about the routing table size, it is not multihomed sites the
offenders, it is large ISPs fragmenting because of traffic engineering
or because lack of BGP knowledge.

.as

On 3/18/13 2:47 AM, Masataka Ohta wrote:
> Mark Andrews wrote:
> 
>>>> 	Yes, BCP38 is the solution.
>>>
>>> It is not a solution at all, because it, instead, will promote
>>> multihomed sites bloats the global routing table.
>>
>> How does enforcing that source address entering your net from
>> customers sites match thoses that have been allocated to them
>> bloat the routing table?
> 
> First of all, multihomed sites with its own global routing
> table entries bloats the global routing table, which is the
> major cause of global routing table bloat and is not acceptable.
> 
> Then, the only solution is to let the multihomed sites have
> multiple prefixes, each of which is aggregated by each
> provider.
> 
> But, then, all the end systems are required to choose the proper
> source addresses corresponding to destination addresses, which
> requires IGPs carry such information.
> 
> See draft-ohta-e2e-multihoming-05 for details.
> 
>> Now if you only accept address you have allocated to them by you
>> then that could bloat the routing table but BCP 38 does NOT say to
>> do that.  Simlarly URP checking is not BCP 38.
> 
> That BCP 38 is narrowly scoped is not my problem.
> 
>> With SIDR each multi-homed customer could provide CERTs which proves
>> they have been allocated a address range which could be feed into
>> the acl generators as exceptions to the default rules.  This is in
>> theory automatible.
> 
> The problem is not in individual ISPs but in the global routing
> table size.
> 
>> How does that solve the problem?
> 
> In the end to end fashion.
> 
> See draft-ohta-e2e-multihoming-05 for details.
> 
> 						Masataka Ohta
> 
>