[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New SOI features draft
I don't think Paul's document talks about anything that I haven't discussed
in the past, so for the sake of helping the discussion along, I'll summarize
my opinions here.
The IPsec WG has already reinvented the wheel twice, for mostly superficial
reasons. Now we have the choice between fixing some specific problems with
IKEv1 or reinventing the wheel again. I prefer the devil I know to the devil
I don't.
I don't think we should cripple the protocol for the sake of advancing
somebody's political agenda. A method for extensions and vendor ids is
essential. No matter what we do, we are going to run into unforseen
incompatibilities with other protocols, (e.g. the ACK-spoofing on satellite
connections or the sequence number problem with QoS or the problems with
dynamic ports).
People should be able to support whatever combination of encryption and
authentication algorithms they want, including shared secrets. However, I
welcome the idea of GUI ciphersuites to facilitate one-click
interoperability. I think the distinction between negotiation of algorithms
and ukases is BS; they are both negotiation. I do like the new wire formats
for the SA proposals, though. Almost anything would be preferable to what we
have in IKEv1.
We should support identity protection to the extent that it's easy to do.
Protection against passive attacks in both directions is best because then
you don't have to worry about asymmetrical rekeying. I think that the
protocol ought to have plausible deniability. The PD provided by IKEv2 and
JFKr with RSA Sigs is not perfect, but I think it is adequate.
I think we should rationalize the use of PFS by correlating the lifetime of
keymat with the lifetime of the SAs it creates.
Control channels have proven useful in the past. I don't discount the
possibility of using an IPsec SA as a control channel (although hijacking a
data channel would be annoying), but I am wary of a protocol that attempts
to avoid control channels altogether. Also, I will speculate that the QoS
will be an important consideration in the future.
I think that adding 2 extra messages when under attack is the best
engineering trade-off for DoS protection. The bogus UDP fragmentation
avoidance strategy described in IKEv2 is good, although I don't think people
will implement it in the near future due to the layer violation. The
technique in JFK may be superior, but it's an even worse layer violation.
Birth certificates are a worthwhile idea, but they don't solve all the link
state problems, such as when a host crashes and never comes back up (or gets
assigned a different IP in a mobile scenario).
I don't want us to remove all of the error messages from the protocol. Some
tweaking of the current error cases would be nice, though. (I am willing to
volunteer.)
IKEv2 is quite different from v1, so I'm not sure it's going to allow us to
reuse as much of the protocol code as I originally thought. However, what I
realize is that many sections of the ike process that perform tasks other
than IKE negotiation (such as the event handler and the policy engine) can
remain largely unchanged, so IKEv2 really does provide a tangible benefit in
terms of code reuse.
I would also like us to ensure that we remain compatible with the MSec WG.
GDOI is based on IKEv1, and it would be very easy for them to integrate with
IKEv2 as well, but not with JFK.
Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Barbara Fraser
> Sent: Tuesday, May 07, 2002 9:46 PM
> To: ipsec@lists.tislabs.com
> Subject: New SOI features draft
>
>
> Thanks to the IKEv2 and JFK folks, and Paul Hoffman for
> developing the SOI
> features document. Ted and I would like to urge you to read it and to
> discuss it on the list. We need to decide which features are
> important to
> SOI so that we can move forward with the protocol design
> work. On page 3 of
> the document, there are three identified core differences
> between IKEv2 and
> JFK: 1) whether the protocol has one phase or two phases, 2) how DoS
> attacks are thwarted, and 3) the use of shared secret authentication.
> According to the document, one path the working group can
> take is to decide
> which of these three differences is important and to then
> select among the
> remaining features.
>
> The scenarios where IPsec/IKE is being used, as described in Cheryl's
> document, are not included in the features document.
> Therefore, one area we
> must explore is the match between the above 3 differentiating
> qualities and
> the community's use and expectation of IPsec/IKE. Is there an
> installed
> base that expects these features to be present, and given the
> answer, what
> does the working group want to do.
>
> Let's see if we can come to consensus in the next month. This
> would allow
> some time for a new or updated protocol draft to be prepared
> prior to the
> July IETF meeting.
>
> thanks,
> Barb
>