One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway.
While I like the idea of some “other” box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the “other” box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit.
Gary
[IPsec] Reauthentication extension for IKEv2
Martin Willi writes:
> What do you think about such an extension? Already considered something
> similar, or does your reauthentication procedure work hassle-free? I'm
> wondering if we are the only ones facing these problems or if such an
> extension would gain broader acceptance...
The first question I have is why are you doing reauthentication at
all?
What is the benefits of the reauthentication?
What is the benefits of the reauthentication that can be done WITHOUT
user intervention (i.e. no user typing in password or pin code or
fingerprint or similar)?
I myself can only really see benefits from reauthentication when it
does require that user is really sitting there on the machine, and
gives something that the machine itself cannot give. In those cases
the user is required to type in something or do something anyways,
thus it does not really matter if the communications is interrupted
for second if user must stop his work for much longer time to type in
his passphrase or pin code.
The RFC 4478 simply skips this question and says "With some IPsec
peers, particularly in the remote access scenario, it is desirable to
repeat the mutual authentication periodically. The purpose of this is
to limit the time that security associations (SAs) can be used by a
third party who has gained control of the IPsec peer."
In most cases if third party has gained control of the IPsec peer he
will also get control of all authentication information inside the
peer, including private keys and pre shared keys. Only way to make
sure that he does not get access to those is to protect them with
passphrase, or pin code or similar that is only known by the user.
This is also said out in the RFC 4478: "However, in the remote access
scenario it is usually up to a human user to supply the
authentication credentials ..."
Because of this I do not think there is that much requirement for
reauthentication protocol that is faster than what we already have.
--
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE
Scanned by Check Point Total Security Gateway.
