[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: