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

Re: [RPSEC] rate limiting management traffic, redux

On vrijdag, apr 18, 2003, at 14:33 Europe/Amsterdam, Stephen Kent wrote:


This is similar to something I proposed about a month ago:



I don't recall seeing your message on RPSEC. Also, it's still a bit 
hard to translate what you said above, into a more general description 
of the sort I provided, complete with a rationale of why it might 
suffice.



It was part of a more extensive discussion, but I agree your 
description is more thorough and more general.




Some stream ciphers are slow to compute an arbitrary value in the 
stream, vs. the "next" value, so the description you have above is 
more specific that my general proposal (in specifying stream ciphers) 
but it still needs to be narrowed to select the right sort of one-way 
function.


Of course.




This means the crypto is done on the cards. Doing this beforehand 
elsewhere and then simply upload the results to the linecard is 
probably a better idea. A linecard with crypto hardware could of 
course do this on the fly but if we have such a linecard why not 
simply do IPsec AH?




One could pre-compute sequence number/tag values and download them to 
line cards, but I would suggest this only if the function was too slow 
to effect in real time on the cards.



Even if you _can_ do it on the fly, that doesn't mean it is preferable 
to do it that way. The whole point of the earlier stuff I mentioned 
above was to not have to do crypto for each incoming packet, but rather 
for each expected valid packet. This should be doable in software, or 
with the assistence of crypto hardware without the requirement that 
this crypto hardware be able to keep up with line rate on all 
interfaces.




There is a big difference between doign what I suggested and doing AH. 
The integrity check in AH covers most of the packet and thus will take 
longer to compute than a function that has only a key and a sequence 
number as inputs. Also, the AH integrity check skips some but not all 
IP header fields, making it complex to compute. So, this is an 
"apples/oranges" sort of comparison!



Yes, but if you have a perfectly good apple tree, is a craving for the 
occasional orange reason enough to build a green house so you can grow 
them?



In other words: yes, your integrety check is cheaper than full AH, but 
is it worth the trouble to implement a new protocol in hardware? If I 
were buying crypto hardware, I'd rather have it do full line rate IPsec.




'm not sure requiring this bitmap is a good idea, as id adds 
complexity (that may need to be burnt into silicon).




Huh? You refer to the IPsec sequence number management mechanism in 
your quote, but the use of a bit map to track arrived packets within 
the window is exactly the nominal implementation approach for this, as 
described in RFC 2406 & 2406. What did you mean when you referred to 
IPsec sequence number management?



I don't think I mentioned the management of the sequence number, just 
the replay counter field. Having the bitmap processing would be a good 
feature, I'm just not sure it's a good idea to require it. Let the 
implementers worry about this.




If we're doing IPsec, we already have the anti-replay counter that I 
think can easily do double duty here. For the tag we either have to 
create a completely new option or extend IPsec. Alternatively, the 
tag can be used as (part of) the IV for ESP processing.




Yes, if we use IPsec for end-to-end security, one could definitely use 
that sequence number field, but I didn't know if people wanted to make 
that assumption for this mechanism.



Currently IPsec ESP supports authentication and encryption, maybe this 
could be an additional IPsec service?




	- how big is the sequence number and how big is the tag





The sequence number wraps all the time so 16 bits should be adequate 
or maybe 32 bits. As a typical window would be something like 64 
packets, with a 32 bit tag an attacker has a one in 500 million 
chance of guessing a valid tag. A 10 Gbit link can carry several 
million packets per second so the attack would hit paydirt in a 
matter of minutes with 32 bits. So I'd say at least 48 bits.




Recall that for IPsec we moved to support 64 bit sequence numbers (vs. 
32 bit numbers) to better accommodate high speed links, so I a 32 bit 
sequence number is probably the smallest I would consider, and 64 
would be preferable.



Note that the requirements here are very different from those in 
regular IPsec. In IPsec, data rates may be very high, and the overhead 
in creating a new SA is considerable. In this scheme, the data rates 
are in the order of one Mbps or less and the overhead of increasing the 
window is very small. So there is no need to support a large sequence 
number space, a simple sliding window pointer is sufficient. Even 6 
bits could be enough. The other end can simply fill in the missing bits 
to arrive at the desired sequence number length.




The tag size is a crypto issue, as well as the key size, so all of 
these parameters need to be considered as a whole.



It's not a traditional crypto issue. After thinking about it a bit more 
I realized my earlier reasoning that the tag should be at least 48 bits 
doesn't hold. With a 32 bit tag an attacker has a 1 in 4 billion chance 
of guessing a valid tag/sequence combination. Even with millions 
abusive packets per second that means the CPU only gets to see a hand 
full per hour. That's more than adequate. And a smaller tag has the 
advantage that it makes analysis by an attacker more difficult, I think 
there are some remarks about this in one of the IPsec documents on 
authentication.



_______________________________________________

RPSEC mailing list

RPSEC@ietf.org

https://www1.ietf.org/mailman/listinfo/rpsec