[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Part II: Summary of responses: Network World article on IPSec
The set of responses was corrupted/truncated. Here is the set of
all responses to Question 3:
>-------------------------------------------------------------------
>3. "And IKE, as it now exists, handles time-expiration of session
> keys in a way that could cause one gateway not to understand
> another."
>
> [Anne] Is this referring to the use of kbytes-based lifetime
> payloads versus seconds-based lifetime payloads? To what extent
> is this a barrier to deployment? Does it just cause a delay, or
> is it a Big Problem?
[Steven Bellovin]:
IKE will definitely need another round. And there's another issue
-- as best I can tell, certificates don't interoperate between
platforms. But both that and your point 3 won't affect people who
use single-vendor solutions for now.
[Bob Moskowitz]:
No this is perhaps the REAL problem. We have implementations that
are to spec that will not interoperate, ie we have some challenges
in the spec. Problem is that phase I lifetime operations are NOT
spelled out in any of the documents, and some vendors have used the
phase II rules. This appears to be incorrect. We have seen two
products, that out of the bos will not work together. To get
interoperation, we have to configure one for infinite phase I
lifetimes and count on the other's local policy to force the
deletion of the ISAKMP SAs on both sides according to its phase I
lifetime.
Phase II so far has not been a problem, but there is a potential
problem there.
Exactly true [commenting on Steven Bellovin's response]. IKE will
be cycled at level due to enhancements. Cert usage is only now
being well defined. Some multi-vendor situations work, not all.
[David Mason]:
This is a more serious problem than just lifetime expiration
... Deletion of SAs due to one side rebooting has been somewhat
addressed by the initial contact message but there are still some
serious problems in this area as well.
Corporations are already deploying IPSec/IKE so I guess neither of
these obstacles are considered big drawbacks by everybody.
[Michael Richardson]:
No, it refers to some minor, unclear text. In this case it meant
that two products would not communicate out of the box. That isn't
to say that they couldn't be configured to communicate. That is why
we have a proposed standard stage that requires actual use. That way
we discover the problems now. If we didn't deploy, then we wouldn't
find the problems.
[Derrell Piper]:
Again, utter crap. There are some incomplete implementations which
do not currently include support for the mandatory lifetime
attributes. As a result, certain other gateways will refuse to
negotiate with them because of security policy which says that
lifetime negotiation is required. This is hardly a problem with the
protocol.
It is true that from an implementation perspective, getting rekey
right is somewhat complicated in this architecture. There is work
underway in IPsecond to write some guidelines about how to do rekey
correctly. However, as someone who has written code, it certainly
can be done interoperably.
[Scott Kelly]:
I think this refers to the so-called 'rekey problem'. That problem
exists due to an unforseen complication introduced due to a design
simplification. SAs are, by definition, unidirectional, meaning that
in order for us to have a 2-way conversation, 2 SAs are required:
one from me to you (over which I send data), and one from you to me
(over which you send data). Technically, these 2 SAs should be
negotiated in separate IKE exchanges, but as a matter of
convenience, they have been combined into one negotiation,
effectively rendering the SA bidirectional.
For unidirectional SAs, rekeying (i.e. negotiating a new SA because
the first one is expiring) is simple: for the SA extending from me
to you, if I want to continue, I renegotiate a new SA, and delete
the old one once I'm finished. The same applies to you, if you wish
to continue protecting packets on the return path.
For bidirectional SAs, it's a bit more involved, i.e. how do we
decide who is responsible for rekeying? The problem arises here,
when both sides attempt to rekey at almost exactly the same time. A
quick fix that was proposed was to introduce random jitter into the
SA timer, meaning to store a value that is less than the negotiated
value by some small random amount, thus lessening the probability of
a rekey collision. However, some vendors still have problems with
the logistics of this, so a mechanism needs to be agreed upon and
formalized. Hardly earth-shaking...
[Pyda Srisuresh]
Lifetime issue is quite relevant to remote access. Remote access clients
are prone to logging in frequently (as opposed to attached to the net
all the time). The existing lifetime metrics do not guarantee that an SA
established for one user does not get deleted when the user terminates
the connection. Clearly, IKE on either end should clean up SAs when
network-login is terminated. A new metric like "network-connected-time"
would be useful for remote access users.
Also, interoperability issues with regard to session rekeying upon
lifetime expiry should be addressed independent of remote access clients.
--
Anne Anderson Email: aha@east.sun.com
Sun Microsystems Laboratories or: aha@acm.org
2 Elizabeth Drive, UCHL03-205 Tel: (978) 442-0928
Chelmsford, MA 01824 USA Fax: (978) 250-5067