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

Summary of issues from RTP (third/IETF edition)

Here are the interoperability issues as presented at IETF-LA.  Most of
these were from the ANX bakeoff as stated by Michael Richardson's email.
 Those items with (******), have added discussions.

1. ISAKMP SPI Sizes
Some implementations got upset (i.e. crash) when offered different sizes
of SPIs
eg. 2 octets was required for IP Comp

2. Correctly Ordered Payloads
For some vendors, ISAKMP payloads had to be in the order that they are
documented.
Most ISAKMP payloads may be sent in any order (except for the SA,
Proposal and Transform payloads)

3. IP Addresses in Certificates 
Some people expected strings, other expected 4 octets in ipAddress
"It is never a string when encoded in subjectAltName"

3. IP Addresses in certificates
"... consensus was that if IP Addresses (or dns name or rfc822 name)
were going to be added to an X.509 certificate then they should go into
the subjectAltName extension (that is after all what it is for).  This
is consistent with work done in the PKIX WG"

4. No IP Address in Certificate
An IP Address does not have to be within the certificate if the IPSec
entity is mobile and uses a dynamic address

But, there must be some other type of identity within the certificate
(rfc822name, domain name, X.500 DN)

5. Replay of Zero (******)
Some implementations were sending a replay prevention value of 0 when
doing manually keying

****** This is incorrect behavior, since the replay prevention field
must be incremented. ******
6. AH & Auth Attribute
Some vendors were not sending both the AH Transform type (e.g. AH_MD5)
and the Authentication Algorithm attribute (e.g. HMAC-MD5) 
Some vendors would not accept receiving both the Transform type and the
Authentication Algorithm attribute

7. New CertReq Format
Some vendors were using the old isakmp-08 certificate request format

8. Hash in RSA Encryption
Some vendors did not like getting a key hash payload in rsa encryption
mode 

9. Unknown Notify Payloads
Some vendors were discarding entire ISAKMP packet when an unknown notify
payload was received (ie. INITIAL-CONTACT)
Only the single Notify payload should be discarded

10. Handling CertReq
Some vendors did not like receiving certificate request payloads when
using pre-shared keys
The isakmp draft says certificate requests payloads can exist in any
message
Some vendors did not like receiving certificate request payloads at any
time

11. Packet Padding (******)
Some vendors did not like ISAKMP packets to be padded to a multiple of 4
byte.
The ISAKMP draft states that the ISAKMP message MUST be 4-octet aligned

****** Actually, the draft is incorrect and will be modified.  No
alignment is required for ISAKMP messages ******

12. IDui & Idur
Some vendors expected to see client ID's in phase 2 (QuickMode), even
though they are optional
This caused QuickMode to complete, but fail to setup the correct SAs

13. IP4_ADDR_RANGE
Some vendors do not accept a QuickMode ID type of IP4_ADDR_RANGE while
they do accept IP4_ADDR and IP4_ADDR_SUBNET

14. Nonce Sizes
Some vendors could not handle larger sized nonces (40 bytes) and would
only allow 20 byte nonces
The new IKE document does state:
"The length of nonce payload MUST be between 8 and 256 bytes inclusive."

15. Overlapping SAs
Some vendors did not support having a SA with the whole subnet at the
same time as another SA with one host in that subnet

16. CONNECT Notify Message (******)
Due to QuickMode's 1.5 exchanges, the initiator might not know that the
responder did not receive the 3rd message
One vendor suggested we should send a Notify CONNECT message for the
responder's 2nd quickmode message

****** This is not necessary because of the COMMIT bit in the ISAKMP
header. ******