why is SA lifetime kilobyte limit disabled in racoon?
Matthias Drochner
Hi -
racoon does not allow to specify a lifetime type of kilobytes.
A config file containing such a rule is rejected; the message is
"byte lifetime support is deprecated".
I haven't found any reference why this is the case, and no
other IKE implementation which doesn't allow asuch a volume
limit.
Someone asked about that on the KAME mailing list but didn't
get an answer.
Does anyone here remember of a reason why racoon does
do this?
(Not that I need it, but it causes confusion.)
best regards
Matthias
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
hsue...@iij.ad.jp
I've heard about one of the problem of supporting life-bytes is
"when is IPsec-SA marked as used?"
When Node-A sent a 1500 bytes packet to Node-B, Node-A marked
IPsec-SA as used and count used-bytes up. But the packet may
lost. In this case, Node-B can't count used-bytes. Even if
Node-A think IPsec-SA is expired at this time, Node-B doen't
think so. i.e. the states of IPsec-SA is mismatched.
Racoon's strategy of rekeying is "Initiator do it." If Node-B
is responder, Node-A doesn't start rekeying even if IPsec-SA is
expired.
The packet may lost in Internet, and also lost in protocol stacks.
Works of protocol stacks are implementation issue. So life-byte
behavior has interoperability problem.
I don't know this is all of the problem or not...
I want to know other reasons if someone know it.
----------
Internet Initiative Japan Inc.
Product Technology Section,
Product Development Division,
SEIL Business Unit
SUENAGA Hiroki <hsue...@iij.ad.jp>
Steven Bellovin
On May 18, 2011, at 10:15 38PM, hsue...@iij.ad.jp wrote:
> Hi Matthias,
>
> I've heard about one of the problem of supporting life-bytes is
> "when is IPsec-SA marked as used?"
>
> When Node-A sent a 1500 bytes packet to Node-B, Node-A marked
> IPsec-SA as used and count used-bytes up. But the packet may
> lost. In this case, Node-B can't count used-bytes. Even if
> Node-A think IPsec-SA is expired at this time, Node-B doen't
> think so. i.e. the states of IPsec-SA is mismatched.
>
> Racoon's strategy of rekeying is "Initiator do it." If Node-B
> is responder, Node-A doesn't start rekeying even if IPsec-SA is
> expired.
>
> The packet may lost in Internet, and also lost in protocol stacks.
> Works of protocol stacks are implementation issue. So life-byte
> behavior has interoperability problem.
>
>
> I don't know this is all of the problem or not...
> I want to know other reasons if someone know it.
While I don't know the precise reason, I will note that byte
count expiration is much less of an issue with AES than with
DES or 3DES.
The problem with DES and 3DES is that they use 64-bit blocks,
which means that you start running into birthday paradox problems
after 2^32 blocks, i.e., 2^35 bytes. On modern, high-speed nets,
that isn't at all out of the question. AES, by contrast, uses
128-bit blocks, which raises the threshold to 2^68 bytes, which
is about 7000 years at 10GigE speeds...
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Greg Troxel
When Node-A sent a 1500 bytes packet to Node-B, Node-A marked
IPsec-SA as used and count used-bytes up. But the packet may
lost. In this case, Node-B can't count used-bytes. Even if
Node-A think IPsec-SA is expired at this time, Node-B doen't
think so. i.e. the states of IPsec-SA is mismatched.
Racoon's strategy of rekeying is "Initiator do it." If Node-B
is responder, Node-A doesn't start rekeying even if IPsec-SA is
expired.
That sounds like a bug in racoon. It seems that if either end is
unsatisfied with the SA, that end should trigger a new one. But the key
question is what the other implementions do, and what the standard says.
That said, I can see the argument that especially with a 24h or less
lifetime, AES doesn't need volume-based rekeying.
Matthias Drochner
> Even if
> Node-A think IPsec-SA is expired at this time, Node-B doen't
> think so. i.e. the states of IPsec-SA is mismatched.
Understand -- similar things already happen with time-based
lifetimes if there is a clock skew between the two boxes.
(This is particulary bad if the oldest available SA is used
by the kernel.)
> Racoon's strategy of rekeying is "Initiator do it." If Node-B
> is responder, Node-A doesn't start rekeying even if IPsec-SA is
> expired.
> That sounds like a bug in racoon. It seems that if either end is
> unsatisfied with the SA, that end should trigger a new one.
I'd also call this a shortcoming at least. The standards are
weak, and one doesn't know how other implementations behave.
It would be safer if both sides did care about renegotiations.
> But the key
> question is what the other implementions do, and what the standard says.
I've just tried OpenBSD's isakmpd (the oldish version in pkgsrc).
It initiates a Phase 2 exchange if the soft timeout on its
side expires, even if it was responder initially. (It randomizes
the soft timeouts to minimize the chance that both sides start
the exchange simultanously.)
PFC2409 says that both sides can initiate rekeying. "Can" --
this is not much of a guideline for implementors.
> I can see the argument that especially with a 24h or less
> lifetime, AES doesn't need volume-based rekeying.
OK, I was more concerned about interoperability. What if
the other side insists in some volume limit?
Greg Troxel
Matthias Drochner <M.Dro...@fz-juelich.de> writes:
>> But the key
>> question is what the other implementions do, and what the standard says.
>
> I've just tried OpenBSD's isakmpd (the oldish version in pkgsrc).
> It initiates a Phase 2 exchange if the soft timeout on its
> side expires, even if it was responder initially. (It randomizes
> the soft timeouts to minimize the chance that both sides start
> the exchange simultanously.)
> PFC2409 says that both sides can initiate rekeying. "Can" --
> this is not much of a guideline for implementors.
True, but it seems the original responder initiating a renegotiation is
the only reasonable behavior.
>> I can see the argument that especially with a 24h or less
>> lifetime, AES doesn't need volume-based rekeying.
>
> OK, I was more concerned about interoperability. What if
> the other side insists in some volume limit?
Then I think it's in the proposal, and agreed to or not. But if the
other side just asks to renew the phase 2 sa, I think that works,
standards wise, and might actually work.
Thor Lancelot Simon
>
> Matthias Drochner <M.Dro...@fz-juelich.de> writes:
>
> >> But the key
> >> question is what the other implementions do, and what the standard says.
> >
> > I've just tried OpenBSD's isakmpd (the oldish version in pkgsrc).
> > It initiates a Phase 2 exchange if the soft timeout on its
> > side expires, even if it was responder initially. (It randomizes
> > the soft timeouts to minimize the chance that both sides start
> > the exchange simultanously.)
> > PFC2409 says that both sides can initiate rekeying. "Can" --
> > this is not much of a guideline for implementors.
>
> True, but it seems the original responder initiating a renegotiation is
> the only reasonable behavior.
At the very least, it would appear to suggest that if the original
initiator rejects an attempt on the part of the original responder to
rekey, that's a bug.
Which is sufficient, no?
Thor
hsue...@iij.ad.jp
On 2011/05/20, at 8:22, Greg Troxel wrote:
>
> Matthias Drochner <M.Dro...@fz-juelich.de> writes:
>
>>> But the key
>>> question is what the other implementions do, and what the standard says.
>>
>> I've just tried OpenBSD's isakmpd (the oldish version in pkgsrc).
>> It initiates a Phase 2 exchange if the soft timeout on its
>> side expires, even if it was responder initially. (It randomizes
>> the soft timeouts to minimize the chance that both sides start
>> the exchange simultanously.)
>> PFC2409 says that both sides can initiate rekeying. "Can" --
>> this is not much of a guideline for implementors
>
> True, but it seems the original responder initiating a renegotiation is
> the only reasonable behavior.
If both side start rekeying at same time, there is/was a problem of
SA selection.
The two rekeying session makes two pair of IPsec-SAs. racoon can
do this, and IPsec implementations (kernel side) do one of following:
a. Use oldest IPsec-SA to send and keep all IPsec-SAs to receive(KAME)
b. Use newest IPsec-SA to send and keep all IPsec-SAs to receive(Fast IPsec)
c. Use newest IPsec-SA to send/receive and purge older IPsec-SAs
Of cause, c. is bad behavior, but small implementations(kernel side)
may handle only one sessions and one key pair at a time.
Standards don't prohibit this. This problem is exist between IKE
standards and IPsec standards. It seems IKEv2 makes this more clean.
Today, most implementations select b. or have configuration for it.
And racoon isn't used on other than KAME, Fast IPsec, or Linux(a. or b.)
I think your logic actually works fine. But racoon is old product,
so it doesn't catch recent trends up.
----------
Internet Initiative Japan Inc.
Product Technology Section,
Product Development Division,
SEIL Business Unit
SUENAGA Hiroki <hsue...@iij.ad.jp>
Matthias Drochner
s...@cs.columbia.edu said:
> While I don't know the precise reason, I will note that byte count
> expiration is much less of an issue with AES than with DES or 3DES.
>
> The problem with DES and 3DES is that they use 64-bit blocks, which
> means that you start running into birthday paradox problems after 2^32
> blocks, i.e., 2^35 bytes. On modern, high-speed nets, that isn't at
> all out of the question. AES, by contrast, uses 128-bit blocks, which
> raises the threshold to 2^68 bytes, which is about 7000 years at
> 10GigE speeds...
It seems to me that there is also a need for an expiration by
packet count, if IV uniqueness is important.
AES-CTR eg has an IV space of 64 bits. With randomly generated
IVs (as the KAME and FAST_IPSEC code does on all BSDs AFAICS)
the same birthday paradox argument holds -- after 2^32 packets
even if the blocksize is 128 bits.
Or - being clueless about cryptography - am I missing something?
Since a packet count limit is not negotiated through IKE AFAIK,
this is a local decision, and one can't assume that both ends
of the line use the same limit.
This also would require that both sides are able to initiate
rekeying at any time.
(And/or another IV generation method could be used here, 64-bit LFSR
or so. I'll leave that to the experts.)
Matthias Drochner
g...@ir.bbn.com said:
> > PFC2409 says that both sides can initiate rekeying. "Can" --
> > this is not much of a guideline for implementors.
> True, but it seems the original responder initiating a renegotiation
> is the only reasonable behavior.
Why? With racoon, only the original initiator can initiate a
renegotiation. Your hypothetical IKE implementation wouldn't
interoperate with racoon.
As said, I think for best interoperability there shouldn't
be any assumptions like this. Each side should renegotiate
if it thinks its soft timeout (which is a local assumption
anyway) is expired.
[volume limit]
> > OK, I was more concerned about interoperability. What if
> > the other side insists in some volume limit?
> Then I think it's in the proposal, and agreed to or not.
But If I can't even specify in my local configuration that
I want to put a volume limit into my proposal or accept
one from the other side, it is possible that the negotiation
doesn't succeed - depending on the implementation at the
other side.
Matthias Drochner
hsue...@iij.ad.jp said:
> The two rekeying session makes two pair of IPsec-SAs. racoon can do
> this, and IPsec implementations (kernel side) do one of following:
>
> a. Use oldest IPsec-SA to send and keep all IPsec-SAs to
> receive(KAME)
> b. Use newest IPsec-SA to send and keep all IPsec-SAs to receive(Fast
> IPsec)
> c. Use newest IPsec-SA to send/receive and purge older IPsec-SAs
Thanks that you mention that problem -- this was my other question
on the mailing list.
> Of cause, c. is bad behavior, but small implementations(kernel side)
> may handle only one sessions and one key pair at a time.
I think that even if we avoid assumptions about things not clearly
stated in the standards, we can safely assume that an implementation
will not fall back to an old key once it started using a new one
for sending. This means one could safely remove old SAs after one
receives packets with the new SPI. Well, only authenticated ones
should count... This is not easily done in BSD due to kernel /
userland abstractions, but feasible for embedded systems.
> Today, most implementations select b.
The problem with b is that the phase 2 initiator can't be sure that
the other side has the receive SA installed. The third message
of the 3-way handshake might be lost. I think there should be
a delay in the order of retry_timeout x retry_count before
the new sending SA is used. After that delay, either the
responder side got the third message, or the phase 2 negotiation
is declared failed anyway.
The responder can use the SA immediately. But now we have
an abstraction problem again: The kernel doesn't know about
IKE in general and initiator/responder roles in particular.
So the IKE daemon would have to implement the delay.
> But racoon is old product,
> so it doesn't catch recent trends up.
It is still somewhat maintained, and since there is not much
choice, we shouldn't let it rot...
Matthias Drochner
hsue...@iij.ad.jp said:
> b. Use newest IPsec-SA to send and keep all IPsec-SAs to receive(Fast
> IPsec)
Btw, It seems that the way this is implemented in FAST_IPSEC
interprets the PFKEY RFC rather liberal: As I read it, the
RFC doesn't specify a DELETE message from kernel to userland.
It seems that the original plans were to do all key management
in userland.
Just wanted to mention this...
Steven Bellovin
On May 23, 2011, at 7:06 47AM, Matthias Drochner wrote:
>
> s...@cs.columbia.edu said:
>> While I don't know the precise reason, I will note that byte count
>> expiration is much less of an issue with AES than with DES or 3DES.
>>
>> The problem with DES and 3DES is that they use 64-bit blocks, which
>> means that you start running into birthday paradox problems after 2^32
>> blocks, i.e., 2^35 bytes. On modern, high-speed nets, that isn't at
>> all out of the question. AES, by contrast, uses 128-bit blocks, which
>> raises the threshold to 2^68 bytes, which is about 7000 years at
>> 10GigE speeds...
>
> It seems to me that there is also a need for an expiration by
> packet count, if IV uniqueness is important.
> AES-CTR eg has an IV space of 64 bits. With randomly generated
> IVs (as the KAME and FAST_IPSEC code does on all BSDs AFAICS)
> the same birthday paradox argument holds -- after 2^32 packets
> even if the blocksize is 128 bits.
> Or - being clueless about cryptography - am I missing something?
>
> Since a packet count limit is not negotiated through IKE AFAIK,
> this is a local decision, and one can't assume that both ends
> of the line use the same limit.
> This also would require that both sides are able to initiate
> rekeying at any time.
>
> (And/or another IV generation method could be used here, 64-bit LFSR
> or so. I'll leave that to the experts.)
Precisely. Section 3.1 of 3686 says
3.1. Initialization Vector
The AES-CTR IV field MUST be eight octets. The IV MUST be chosen by
the encryptor in a manner that ensures that the same IV value is used
only once for a given key. The encryptor can generate the IV in any
manner that ensures uniqueness. Common approaches to IV generation
include incrementing a counter for each packet and linear feedback
shift registers (LFSRs).
In other words, a simple counter suffices. Appendix B of the NIST standard
(Special Publication 800-38A) says the same thing. There is thus no
danger of a birthday attack, so one gets the full 64-bit space.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Matthias Drochner
s...@cs.columbia.edu said:
> In other words, a simple counter suffices. Appendix B of the NIST
> standard (Special Publication 800-38A) says the same thing.
OK, thanks... So we'd need to extend the framework to be able to
choose a per-SA IV generation mechanism, and a place to store
its per-SA context... I'll try to get something coordinated
with the other BSDs. Someone alreading reading this???
A concern would be whether a simple counter leaks
too much meta information for the paranoid. At least it
would be a help to fingerprint the OS or estimate uptime.
(One can ask why, if a simple counter is good enough,
the authors of the specification didn't just make a
requirement of this. Then at least the fingerprinting
concern wouldn't arise.)
Or would it be a good idea to obfuscate the counter,
eg using some random bits and a 64-bit block cipher?
Steven Bellovin
On May 23, 2011, at 1:17 54PM, Matthias Drochner wrote:
>
> s...@cs.columbia.edu said:
>> In other words, a simple counter suffices. Appendix B of the NIST
>> standard (Special Publication 800-38A) says the same thing.
>
> OK, thanks... So we'd need to extend the framework to be able to
> choose a per-SA IV generation mechanism, and a place to store
> its per-SA context... I'll try to get something coordinated
> with the other BSDs. Someone alreading reading this???
>
> A concern would be whether a simple counter leaks
> too much meta information for the paranoid.
Sure.
> At least it
> would be a help to fingerprint the OS or estimate uptime.
Depends on how you pick the starting point.
> (One can ask why, if a simple counter is good enough,
> the authors of the specification didn't just make a
> requirement of this. Then at least the fingerprinting
> concern wouldn't arise.)
They didn't require it because that's overspecifying things --
they want to allow the paranoid to do things differently. The
cryptographic security property required is non-repetition
during the life of the key; any scheme that achieves that is
acceptable. What you actually use will depend on other threat
model issues, ones that are outside of the scope of the standard.
It specifically says that a counter or an LFSR are acceptable;
the former is particularly important to say in the standard because
there are other contexts -- for example, CBC IVs -- where counters
are not acceptable.
But you've given another reason why they don't specify it: having
one counter per system, rather than one per SA, is perfectly acceptable
if you rekey at the right time. What is the right time? Well, far
longer than the life of the system or (most likely) our civilization....
The counter wraps -- and requires rekeying -- after 2^64 packets. Let's
assume UDP in transport mode, which has a header size of 64 bits, and
hence would require one AES-CTR operation. We also have to add 16 bits,
for the padding length and next protocol. (More likely, it's 128, given
padding, etc., but let's be really generous.) We thus have to rekey after
no more than 2^64*80 bits. At 10G bps, that's 147,573,952,589, or about
4700 years. Divide that by the number of 10G bps interfaces on your
box... (A better reason to have one counter per SA is to avoid lock
contention, I suspect, but that's also an implementation issue.)
> Or would it be a good idea to obfuscate the counter,
> eg using some random bits and a 64-bit block cipher?
>
That's a lot more code or silicon.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Matthias Drochner
s...@cs.columbia.edu said:
> > At least it
> > would be a help to fingerprint the OS or estimate uptime.
OK, not for the fingerprint -- the mere fact that there is a simple
counter tells something about the OS and perhaps the byteorder.
But there is another argument for a random start value which is
to protect those who don't read manuals and use the cipher
with a static key. Hope that they don't reboot that often that
birthday paradox strikes again:-)
> But you've given another reason why they don't specify it: having
> one counter per system, rather than one per SA, is perfectly acceptable
> if you rekey at the right time.
Actually, the reason that I didn't suggest a per-system counter
wasn't that I'm concerned about overflow.
One is that for an API which accomodates everyone (including the
paranoid), some per-SA state will be needed anyway. I'm more
concerned about a sustaining API, and like to leave crypto
things to those who know more.
And the other is that a global counter would not only leak information
about the system as such but also about the activity of other ipsec
connections. I can't imagine that this would be acceptable for eg a
corporate tunnel endpoint.
Steven Bellovin
On May 23, 2011, at 4:26 05PM, Matthias Drochner wrote:
>
> s...@cs.columbia.edu said:
>>> At least it
>>> would be a help to fingerprint the OS or estimate uptime.
>> Depends on how you pick the starting point.
>
> OK, not for the fingerprint -- the mere fact that there is a simple
> counter tells something about the OS and perhaps the byteorder.
> But there is another argument for a random start value which is
> to protect those who don't read manuals and use the cipher
> with a static key. Hope that they don't reboot that often that
> birthday paradox strikes again:-)
That's why I really dislike counter mode -- it's too easy to make a
serious mistake with it...
>
>> But you've given another reason why they don't specify it: having
>> one counter per system, rather than one per SA, is perfectly acceptable
>> if you rekey at the right time.
>
> Actually, the reason that I didn't suggest a per-system counter
> wasn't that I'm concerned about overflow.
> One is that for an API which accomodates everyone (including the
> paranoid), some per-SA state will be needed anyway. I'm more
> concerned about a sustaining API, and like to leave crypto
> things to those who know more.
> And the other is that a global counter would not only leak information
> about the system as such but also about the activity of other ipsec
> connections. I can't imagine that this would be acceptable for eg a
> corporate tunnel endpoint.
Sorry, I misinterpreted your comment -- you had spoken about a new API
for per-SA state, so I assumed you meant instead of the current global
state.
--Steve Bellovin, https://www.cs.columbia.edu/~smb