[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issues from the bakeoff
There was an IPSec + L2TP (and PPoE too) bakeoff the week of May 24th.
As usual there were issues in interoperability that came up and I'm
presenting them to the list. Not too surprisingly there were no issues
with interoperability of the IPSec protocols, it's all IKE. Also there
were several IPPCP issues that I'll summarize although they're being
taken care of in a different working group in a different area.
I'll mention the general consensus of people at the bakeoff but that's
just as a starting point for discussion. The resolution (if any) of these
issues is work for this group. Please comment to the list.
thanks,
Dan.
--------------------------------------------------------------------------
*) The Commit Bit
- Should this be mandatory for every single QM? The consensus was
no. QM seems to behave fine when the commit bit is not set and
the only difference is the small window of opportunity for
packet loss.
- There was a desire to weaken the requirement that if the bit
is set by either party then it indicates the 4th message must
be sent. It was proposed that if the peer didn't acknowledge
the commit bit in the next message that the peer was not willing
to do it. This didn't get too much support.
- Does the bit have to be set in all messages after the first? That
is not stated in the RFC and we've approached these issues in the
past in an unsoviet-like manner: if it's not forbidden it's allowed.
So, no it doesn't have to be.
*) ID issues
- Are all ISAKMP/DOI identities valid in phase 2? And can pre-shared
keys be used with any ISAKMP/DOI identity? The DOI deals with
phase 2 negotiation and the identities it defines are for phase 2.
But the IKE and DOI authors agreed to include some text in their
respective documents that clarified which identities are valid when.
- How are subnet ids represented? Is 10.20.30.5/255.255.255.0 valid
or does it have to be 10.20.30.0/255.255.255.0? The desire to use
the former was because some extra information was being gleaned
from the "5" by the implementation that did this. Since subnet
identities are only used by intermediate networking devices it
would seem to make sense to require subnet identities to be the
same as any routing advertisement this device would make. Mentioning
RFC1519 in the DOI would do the trick. Is this something that should
be done?
*) Lifetimes
- What is The Right Thing (tm) to do when mismatched lifetimes are
seen in phase 1 or phase 2? The DOI discusses what to do in phase 2
and the new IKE draft attempts (very poorly) to describe what to
do in phase 1. It is entirely permissible to refuse the negotiation
or to accept it and just stick to the locally configured lifetime.
The text in the IKE draft is being rewritten.
*) Rekeying
- There were statements like "we occasionally get out of sync" or "there
are stalls".
- There was confusion over when to stop using the old SA.
- When a 2nd IKE SA is established should the old one be deleted even if
the lifetime hasn't expired?
It is believed that all these issues can be resolved if the use of the
acknowledged delete message (in the new IKE draft) was made mandatory for
both phase 1 and phase 2. So text mandating the use of this exchange when
deleting any SA will be inserted.
*) Failover and Recovery
- If a peer crashes and reboots its SA state is lost. How to sync back up?
One solution is for the box that rebooted to send and unprotected delete
message causing the box that didn't reboot to clear its SAs and begin
an IKE exchange. The other is for the peer that rebooted to begin an IKE
exchange when it receives IPSec packets for which it has no SA. Both are
problematic.
It was suggested that a keepalive mechanism be built into IKE. Several people
already have proprietary keepalive mechanisms in their implementations.
Perhaps the person(s) who brought this up will write up a draft specifying
how this is to be done.
*) Certificate Requests
- Is a NULL certificate request valid? What does it mean? Apparently it is valid
but there was discussion on what it meant. "Send me all your certs" seemed
to be the winner. The trust model for such behavior was not well explained
though. This is really an item for the WG to decide.
- If a certificate request is issued in the first message of Main Mode should
the peer respond back with his certs in the 2nd message and thereby break the
identity protection feature of Main Mode? The consensus was no. RFC2408 doesn't
seem to say that the certs have to be in the _next_ message only that they
have to be sent.
- What is the order of certs in a chain and does it make any difference? The
consensus was that there is no order and it doesn't make any difference.
*) Misc
- Do implementations have to accept an encrypted final Aggressive Mode message?
Yes they do.
- Does the order of ANDed offers make any difference in IPSec encapsulation? No
it doesn't.
- If the responder sends a "no proposal chosen" in response to an initial phase
1 message does he have to send a responder cookie? Yes he does.
- Can transform numbers in the transform payload begin anywhere and do they
have to be sequential? Regrettably, it's yes and no.
- Is it OK to send 3 copies of every single message (which one implementation
was doing)? Yes.
IP Payload Compresion Protocol (PCP) Issues:
As I said, these aren't IPSec WG issues but people are using IKE to negotiate PCP and
these things came up. The appropriate WG needs to deal with these.
- IKE requires consistent attributes accross Quick Mode negotiation. For instance,
when doing PFS the group must be in all offers and it has to be the same group.
What about PCP? Since it has no keys does it need a group definition if the
accompanying IPSec SAs will have PFS?
- Do lifetimes in PCP SAs make sense to negotiate? If so, does a KB lifetime
expire on pre- or post-compressed data?
- Is it valid to pass a SPI (actually a CPI in PCP) of zero? Is this the "well
known CPI"?
- A CPI is two bytes. Is it OK to send a 4 byte one and have the upper two bytes
be zero?
- A PCP RFC seems to say that tunnel mode processing is not possible. Is this true?
Follow-Ups: