[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

issues raised at VPN interoperability workshop

  The eighth IPSec/IKE (now combined with L2TP, PPTP, PPPoE) interoperability
workshop was held in beautiful San Diego, California last week. Issues
raised during interoperability testing were discussed in a "town hall meeting".
Not surprisingly there were no issues with AH or ESP; they're all with IKE.

  The issues fell into 3 basic categories: the "commit bit", certificate
processing, and a catch-all of miscellaneous (or just misc.). I've added the
way the issue was resolved but solicit discussion on the list before they
go into the Son Of IKE. 

  Dan.

----------------------------------------------------------------------------

Commit Bit

  * Can you clear the commit bit during phase 2?

Yes.

  * Is the commit bit even mandatory? If it's not and you don't support it
    what do you do if it's set in an offer? Refuse it?

It's mandatory.

  * What do you do if the commit bit is set but the responder doesn't
    actually send the connected message? 

Same as if the last message w/o the commit bit didn't arrive: retransmit
and give up after X retransmissions.

  * The fourth message is a Quick Mode exchange message with the same message
    ID as the Quick Mode in which the bit was set. 

Cert Stuff

  * What do I do if I receive a CRL request and don't have a CRL? Silently
    ignore it? Send a notify? Same issue for a cert that I don't have.

Silently ignore it.

  * What do I do if the signature validation fails? Send an unprotected notify?

Yes.

  * How do you retrieve a cert chain?

(punted to the PKI requirements doc)

  * What IKE ID should one use with a cert?

This needs WG resolution and probably clarification in DOI or IKE.

  * What does an empty cert request payload mean?

"give me a cert; any cert".

  * How do you request something with a type of PKCS7?

(punted to the PKI requirements doc)

Misc. Negotiation Stuff

  * If the initiator wants PFS and you don't have it configured what should 
    you do? Similarly, if the initiator offers group 2 (5) and you have group
    1 (2) configured what should you do? Similarly, variable lengthed keys
    for ciphers which have variable lengthed keys.

General acceptance for doing what is offered provided it is not expressly
prohibited by policy.

  * What do I do if I get IPSec packets for SAs which I don't currently have?
    Should I send unproteted notifies or begin an IKE exchange with that person
    or do nothing?

This is implementation specific.

  * What sort of padding-- if any-- should be added to variable lengthed
    attributes?

None.

  * What is the meaning of KB lifetime in phase 1 and can we do away with it?

It has no meaning. A request was made to leave it but note that it is not
meaningful.

  * Can IKE payloads be padded with more than 7 bytes?

Yes.

  * Rekeying is an issue. Phase 1 or phase 2 or both?

Tim Jenkin's Rekeying Draft addresses these. If you're having rekeying
problems refer to that draft (which will be a BCP RFC, I believe).

  * Can you send a keylength with a fixed length algorithm?

No.

  * Nuke the authentication-only bit.

The only purpose for this bit is for Key Recovery and a request was made
to remove it from RFC2408. What does the WG think?
Follow-Ups: