At 12:00 AM +0200 4/18/03, Iljitsch van Beijnum wrote:
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. 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.On donderdag, apr 17, 2003, at 22:40 Europe/Amsterdam, Stephen Kent wrote:My new suggestion in this area requires a shared secret (key) between the router and the entity sending the management traffic, either another router or a management workstation. The key is one of two inputs to a one-way function; the other input will be a sequence number which will be carried with the packet.
This is similar to something I proposed about a month ago: "Ok, how about this: we use a stream cipher to come up with a random-looking data stream on both ends and use the IPsec anti-replay counter as a pointer to the part of the data stream that is used as a magic cookie in the current packet. We can then program the line card with enough data to be able to check a certain number of packets per session"
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. 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!A managed device such as a router maintains a separate key for each entity that is authorized to send management traffic to the device. For each authorized sender, the managed device maintains the following information: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?
- the address of the sender
- the shared secret
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?- a receive window consisting of the sequence number for the most recent, valid management packet from the sender, a sequence number indicating the edge for "too old" packets, plus a bit map marking received , valid packets within the window.I'm not sure requiring this bitmap is a good idea, as id adds complexity (that may need to be burnt into silicon).
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.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.There are a few open issues: - where to carry the sequence number and tag
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. 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.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.- how big is the sequence number and how big is the tag
This is something the crypto experts should answer. I suspect that doing a one-way function over some static data and a sequence number doesn't provide enough entropy from one packet to the next to be secure, even for this purpose. My non-expert guess is that a stream cipher with the sequence number as a pointer to the stream would be better.- how big is the key - what one-way function to use
Yes, let's not play cryptographer here. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec