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

IBM VPN Bakeoff Issues



Title: IBM VPN Bakeoff Issues

There are IPSec issues that were brought up at last week's IPSec bakeoff:

1. All vendors must support the "Vendor ID" payload. Ignore it if you want, but don't crash.

2. Some vendors don't handle tunnel mode with the same inner and outer addresses.  This is a valid configuration and should be supported.

3. It is invalid to send a key length attribute with a fixed-length cipher algorithm.

4. The size of SPIs in NOTIFY messages is ambiguous.  Some vendors send zero bytes while others send 16 bytes.  We need to clarify the wording in the documents.

5. Some vendors require that the insignificant portion of an address part of a subnet address be zeroed (ie. 10.1.1.0/255.255.255.0 instead of 10.1.1.23/255.255.255.0).

6. What SPI should be sent in a DELETE message?  Some vendors send zero sized SPI, some send 16 bytes of SPI.

7. Attributes other than life-duration and life-type must not be duplicated in the same transform.  Those two attributes must only be included a maximum of twice and the life-type attribute must have different values. (ie. seconds and kilobytes)

8. DH Group 5 needs to be documented.  A lot of vendors support this group.

9. Should the order of protocols dictate the order of security association or should AH, ESP, IPComp always be processed in a certain order?  Most vendors agreed with the latter.

10. Some vendors were changing the order of the ID payloads when they were responders.  Some other responders were also changing ports. This is incorrect behaviour.

11. Key length is not defined for phase 1 negotiations.  Actually it is defined in IKE v.8 as attribute #14.

12. Does ESP-NULL require padding (the ESP doc says 4-byte alignment, ESP-NULL doc says 1-byte alignment).  The consensus was that ESP is 4-byte aligned.

13. Microsoft's export DH group is not documented.  Not sure if it needs to be.

14. Is proposing "RC5 with 128 bit key length" the same as proposing "RC5" since 128 bits is the default key size?  Should vendor's be aware of the default key size and equate comparable cipher/key sizes?

15. We still have confusion around the commit bit.

16. If an initiator requests an SA with only a single IP address as the destination, but the responder has a local policy of a subnet (instead of a single IP address), should it fail the negotiation?  Some vendors were doing this.

17. The HASH payload must be the first payload in a info/new group exchange.  This isn't clear in the documents.

18.  Some interest in the Meta ID type.

19. Phase 2 ID payloads are optional and may be absent when negotiating transport mode.  Some vendors required these payloads to be present.

20. It would be nice if Delete messages supported multiple protocols instead of just one protocol.  This is handy for deleting SA bundles.

21. The phase 1 IKE SA  cannot expire while its phase 2 negotiation is in progress.

22. We need further clarification on when Notify messages start becoming encrypted.  Some vendors start encrypting after message 4 of MainMode, some wait until phase 1 complete.

23. We need further clarification concerning the authentication algorithm's use when negotiating AH.

24. Someone pointed out that the same DH group has to be used for all proposals when using Aggressive Mode and Quick Mode.

25. Someone pointed out that the ID payload is redundant if we are doing RSA_SIG authentication, since the certificate already has the identity.

26. We need clarification on the SPI usage in phase 1's SA payload.  The documents state it can have 0-16 bytes.

27. Vendors should be aware of different IKE version numbers.  Currently v0.1 and v1.0 are defined.  The text needs to be clearer on version numbers.

28. Vendors should report errors according to the ISAKMP document, section 5.  "Invalid Cookie" doesn't cut it.

29. The notify messages need to be explained.  There's currently no description of what any of the NOTIFY codes mean.

30. There seams to be a lot of overlap between ISAKMP and IKE & IPSec-DOI.  This is confusing for IPSec new-comers.

31. Do we allow CertReq payloads in shared-secret mode?  Yup, but you probably don't want to reply back with a certificate.

32. Should proposal rank number start with 1 or zero and should they increase by 1 ?

33. Vendors must support the third AggressiveMode message being encrypted.

34. What should the maximum number of proposals be?  Some vendors only handled a limited number of proposals.

35. What does an empty CertReq mean?  Currently no documentation on this issue.

36. X.500 DN is a valid ID type when doing shared-secret authentication.




Roy Pereira
Senior Product Manager, TimeStep Corporation
(613) 599-3610 x4808
http://www.timestep.com


Follow-Ups: