[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proxy AH (was: An architectural draft)

Masataka,

On donderdag, mei 29, 2003, at 07:21 Europe/Amsterdam, Masataka Ohta wrote:

The source address is something I'd really like to check.



You don't.





If payload passes authentication check, the payload is considered
to be reliable regardless of the source address.




Re the spam discussion on the IETF list: I'd rather know I'm dealing 
with a "good" source rather than check the content of everything I 
receive.




When I get around to it, I plan to write a draft about how ISPs can do
proxy IPsec AH processing for their customers to eliminate denial of
service traffic.





It is an utter violation of the end to end principle and assured
not to scale, which, for example, means poor performance.




Writeups of e2e that I've seen explicitly state that something that 
should be done end-to-end MAY also be done in the network as an 
optimization. As long as it's an optimization and not shifting of 
responsibility it's ok.



I don't see why this shouldn't scale: 10 times more traffic means 10 
times more crypto chips. O(n) scaling isn't that bad.




In this case, a proxy box of an ISP is an easy victim of the DoS
attack.




Good luck DoSing a box that can do crypto at line rate.  :-)



Obviously DoSers can raise the stakes by trying to DoS (some part of) 
the ISP rather than the customer, but I'm not worried about that. ISPs 
typically have bandwidth in the order of gigabits, while customers may 
only have a few megabits. Flooding a 10 Mbps pipe is trivial, and done 
so often stopping it is a problem. Flooding a few 1 Gbps pipes is hard 
and should show up on the radar screens of even the most uncooperative 
source networks so stopping this is much, much easier.




That's why we do AH first and reject the packet if it doesn't check
out. Applications are not involved in IPsec, that's the whole point.
Otherwise you could just as well use TLS.





I'm afraid you are assuming authentication check by ESP is much
slower than that by AH.




No. What I'm saying is that porting all your applications to support 
SSL is much slower than porting your OS to support IPsec.



On donderdag, mei 29, 2003, at 07:39 Europe/Amsterdam, Masataka Ohta 
wrote:




The only thing you can do against DoS is to detect its origin.




That's why we make them get a key that only works for a single origin 
address and use that key in each packet.




The master keys are communicated to the
ISP (for instance by inserting them in a BGP attribute)





in plain text?




Why not? Obviously the BGP attribute wouldn't be transitive, so the 
master keys would stay within the ISP network.




This requires some serious hardware at the ISP side





You are saying you must provide high performance hardware to get
severely limited rate, even though there is no attackers, which
is a lot worse than DoS.




ISPs would need enough of these boxes to easily handle the maximum 
expected DoS traffic. The system would only have to be enabled for a 
certain customer when the customer is under attack. But even if the 
system is enabled all the time there might be situations where the 
protection is worth the extra cost. Obviously this would be an extra 
value added service on top of regular IP transit, rather than a 
standard part of IP.