[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Merging IKEv2 and JFKr?
Some replies to the entire discussion of last week (not just Jan's message):
I acknowledge the need for some compromise. But I do agree with Charlie's
earlier observation that any IKEv2-JFKr will probably be inferior (IMHO) to
the original IKEv2 draft. It was too long in coming, but the IKEv2 draft
really did represent the logical clarification and evolution of IKE. It is
neither unrealistic (what I like to call "simplicity by omission"), nor
politically motivated, nor unnecessarily innovative. So as far as I'm
concerned, any merging of the drafts is going to be more of a "minimize the
damage" type of operation than a "best of both worlds" scenario.
Like Jan said, extensibility is the number 1 concern about any such
Frankenstein/chimera. From our earlier survey, I concluded that there is a
rough consensus (at least among implementers) that extensibility is a good
thing. In my experience, extensibility doesn't just pay off in the long run;
to some extent it pays off now. We don't all live in a fantasy world where
we can wait until a draft reaches Internet Standard status before we start
shipping. Many of us find ourselves constantly chasing a moving target.
Obviously you can't anticipate everything, but failure to account for future
development results in some really ugly kludges... the Internet is full of
them.
BTW, whatever became of the SOI discussion summary that Barbara promised to
post a couple of months ago? It was supposed to summarize the popular
opinion on each issue, confirm the requirements, and influence the design
direction.
In regard to a few other issues that have been brought up recently:
Speaking as someone who successfully implemented the revised hash, I don't
particularly want to go back to the old way of doing it. There are many ways
to handle incoming IKE messages, but for those of us who do most of our IKE
processing on pre-parsed packets it is much easier to sign/hash an arbitrary
blob of data than to assemble the buffer piecemeal.
The half-encrypted message idea doesn't particularly appeal to me, but I
won't claim that we can't handle it. The protocol doesn't rely on encryption
for security, so there's no real danger of this modification introducing
security holes.
I'm really not a big fan of the "repeat payloads from message 1 in message
3" idea. People complained about IKE being too complicated because you need
code to parse every payload twice (once for main mode and once for
aggressive), but this strategy has leads to the same result (plus
fragmentation, bandwidth wastage, etc).
I also endorse the "URL to a cert" suggestion.
I will deal with the 4 vs 6/4 issue in a separate message, since Radia
branched off a new thread.
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 Jan Vilhuber
> Sent: Monday, September 16, 2002 8:27 PM
> To: ipsec@lists.tislabs.com
> Subject: Merging IKEv2 and JFKr?
>
>
> Or "How to dress up Frankenstein to look presentable".
>
> I'm wondering about the wisdom of merging IKEv2 with JFK'isms. Seeing
> that I haven't read the revised IKEv2+JFK proposal (because it's not
> out yet), this is mostly based on my thoughts of what *I* would do,
> were I to merge the two. I expect there's not that many ways to skin
> this cat.
>
> Firstly, it doesn't seem needed. The difference is that JFK
> assumes it's
> ALWAYS under attack, versus IKEv2 that gives you a mechanism to verify
> the initiator's 'liveness' if you think you're under attack. So it's
> not like IKEv2 doesn't address DoS issues. It does.
>
> Code messiness. You may poo-poo that concept, but we all understand
> IKE code and the coding-/design- philosophy behind it. You may not
> like it, but there's a certain amount of expertise out there. By
> adding JFK'isms into the mix, you're now mixing two very different
> philosophies into one protocol, which sounds like it's prone to be
> buggy, hard to analyze, etc etc. Instead of a protocol designed by a
> committee, we now have a protocol designed by TWO committees.
>
> Along the same lines (or maybe 'by example'), IKE has always been
> 'encrypted packet' or 'non encrypted packet'. Now we have a
> 'half-encrypted' packet. Sigh. If someone has a clean way of doing
> this (An 'encrypted payload' similar to Kink's KINK_ENCRYPT payload
> (section 5.1.8 of the kink draft, FWIW) maybe?), maybe this can be
> made to work, if absolutely necessary.
>
> Extensibility: I keep thinking that prior to the SOI discussions, we
> had talked about simplifying IKEv1 hashing, so that ALL payloads are
> hashed and authenticated, no matter what they were. That has clear
> implications to extensibility, i.e. future payloads. I realize one of
> JFK's goals was 'non-extensibility', but I thought I saw rough
> consensus towards extensibility during the recent chinese-menu
> mails... Now by merging JFKr into IKEv2, we complicate the hashing
> mechanism again to the point where we have to think about which
> payloads can be part of the hash and which can't (also, which payloads
> must be repeated and which mustn't or don't need to).
>
> Legacy Authentication: This is really a subset of "extensibility". I'm
> trying to fit some legacy authentication scheme into IKEv2, and I have
> some ideas. Trying to fit them into an IKEv2+JFK protocol (assuming
> what's in my mind is similar to what Charlie is working on) makes it
> that much harder.
>
> Packet sizes: By repeating msg1 in msg3, msg3 necessarily gets
> larger. William kept trying to get people to realize that we have a
> UDP fragmentation issue, when certs (or cert chains) are sent, so this
> seems like a move in the wrong direction. Paul Hoffman had some ideas
> of changing the ID payload so that it can include a URL, i.e. pointer
> to the cert instead of the cert itself, and that may help.
>
> Based on my gut feeling, I vote to leave IKEv2 as is, rather than
> grafting JFK'isms onto IKEv2. If it gave us something we can't live
> without, I wouldn't have that much of an issue with it, but I don't
> see a very good reason to do it (the cost outweighs the gain).
>
> Flame away. "Me too's" or "Ditto's" highly encouraged.
>
> jan
> --
> Jan Vilhuber
> vilhuber@cisco.com
> Cisco Systems, San Jose
> (408) 527-0847
>
> http://www.eff.org/cafe
>
>