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

Re: [RPSEC] rate limiting management traffic, redux

At 4:52 PM +0200 4/18/03, Iljitsch van Beijnum wrote:



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?


Must be an old Dutch proverb ?




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.



No disagreement about what would be ideal, just a matter of 
complexity and cost, which I have been told are concerns for some 
folks :-)






'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.


Yes, the implementation details are a local matter.






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?



ESP mandates support for confidentiality plus integrity, or integrity 
only, or confidentiality only. Since the IPsec WG is trying to 
simplify the range of options, we're dropping mandatory support for 
confidentiality only. I don't see it as likely that we would add an 
"authentication tag not tied to the payload" option.






	- 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.



Yes, legitimate management traffic should arrive at relatively low 
data rates, so maybe a smaller sequence number size would suffice. 
But, the tag size should be big enough to not allow an attacker to 
flood the system with bogus packets for which a non-trivial number 
pass this test.






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.





A tag formed from a truncated hash function output has the advantage 
that an attacker is not able to see all the output bits to try to 
work backwards to the key. But, we have not yet specified the 
function we will use to generate the tag, and so it's a bit premature 
to talk about whether a truncated output from that unspecified 
function is appropriate :-).



Steve

_______________________________________________

RPSEC mailing list

RPSEC@ietf.org

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