RE: Choosing between IKEv2 and JFK

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

> What kind of bloat are we talking about?
>
> > (see IKEv1) and bad APIs (another source of trouble and
> > embarassments).
> >
>
> Underspecification in a protocol definition leads to bad API's, not a
> comprehensive protocol...

Definitely. This fact is often ignored when designing a protocol on paper
(it keeps the complexity-nazis at bay), but it becomes apparent when you're
trying to interop later.


> > As for informational exchanges, surely you jest :-)
>
> Nope.
>
> > I have yet to see an
> > IKE implementation that (a) does anything meaningful on
> receipt of an
> > informational message,
> > or (b) depends on information exchanges for its
> > correct operation.

> That's because so far there's been much confusion surrounding these
> exchanges. If they were clearly spelled out in their use and semantics
> (note: well defined protocol specification), this wouldn't be nearly
> as confusing. We're finding that it's becoming very important to have
> these informational exchanges and are starting to use them more and
> more.

This all depends on what you think the purpose of the notifies is. JFK
obviously intends the notifies to be processed by the initiator and used to
alter its behaviour. I think the notify is more likely to be used as a
troubleshooting tool by the user. If the SA is failing due to some
configuration issue, I like to think that the peer will give me some
indication of what went wrong so that I can display a message to the user
instead of forcing them to call up the remote sysadmin and ask to see the
negotiation logs. Also, our customer support people gradually learn what the
notifies mean, and they how they correlate to various bugs or configuration
issues. An alternative is to send an error message in text, but this brings
up the issue of language choice, and it prevents me from choosing the text I
want to display to the user.

In retrospect, the notifies defined in ISAKMP are quite inadequate. I'm sure
we could improve them, given what we know now. If you remember, there was an
effort to more clearly define the notifies and send a more elaborate
description of the problem, but this wasn't widely implemented, I think
because building and parsing the more elaborate notify payload didn't
integrate well into most people's existing code. Even despite this, when
someone phones me and says customer X can't interop with vendor Y and they
send notify Z, I can usally guess what the problem might be.

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.