[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: issues from the bakeoff
One of the biggest issues we ran into was the handling of Phase 1 rekeying.
We found that quite a few implementations simply drop the Phase 1 SA when it
expires and leave the Phase 2 SAs up. Our implementation does not allow
"orphan" Phase 2 SAs to be left around so we take them all down when we
receive the delete message (if there is a new Phase 1 SA, we transfer all
the Phase 2 SAs to the new one). We are then left with some period of time
where one side is sending data over an SPI that has been deleted by the
other side. This goes on until the Phase 2 SAs rekey and then the problem
clears up.
This is one of those issues that will not be affected by the confirmed
delete and is really just an interpretation of the spec. In my opinion,
Orphan Phase 2 SAs are not a good thing for a number of reasons. I guess
many others do not agree.
What is the right thing to do here?
I apologize if this has been talked about in the past.
Victor
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@network-alchemy.com]
> Sent: Tuesday, June 15, 1999 3:55 PM
> To: ipsec@lists.tislabs.com
> Subject: 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: