[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary of issues from RTP
I forgot to mention that some vendors do not accept a QuickMode ID type
of IP4_ADDR_RANGE while they do accept IP4_ADDR and IP4_ADDR_SUBNET.
>-----Original Message-----
>From: Roy Pereira
>Sent: Wednesday, March 18, 1998 3:06 PM
>To: 'Michael C. Richardson'; 'ipsec@tis.com'
>Subject: RE: Summary of issues from RTP
>
>Also, 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.
>
>>-----Original Message-----
>>From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca]
>>Sent: Tuesday, March 17, 1998 11:02 PM
>>To: ipsec@tis.com
>>Subject: Summary of issues from RTP
>>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>
>>
>> {Don't ask me to present this in LA, I won't be there. The agenda doesn't
>>say whether or not it will be in an MBONE room. If so, I'll be listening,
>>DVMRP tunnel setup permitting. Email me if you can give me a tunnel!!!.
>>
>> I will update this list again on the 27th. I have taken the list, removed
>>the headers, signatures, and reworded some parts. Please let me know if I've
>>screwed up what you are saying.}
>>
>> 1. ISAKMP SPI sizes. Some implementations get upset (i.e. crash) when
>> offered different sizes. (2 octets was required for the IPcomp people)
>>
>> 2. ISAKMP payloads had to be in the order they are documented in the
>>draft.
>> Most ISAKMP payloads may be sent in any order. The exception is that
>> there is a proscribed relationship between some payloads
>> (i.e. proposal payloads, transform payloads, etc)
>>
>> 3. IP address in CERTs. Some people expected strings, other expected
>> 4 octets in ipAddress. If string, then is it: CN vs Unstructured or
>> subjectAltName.
>>
>> 4. Some implementations are sending a replay protection number of 0
>> when manually keying. "I was under the impression sequence # 0 should
>> NEVER go on the wire, but hey, what do I know?"
>>
>> 5. Some vendors are not yet supporting DOI-07 wrt the AH transform type,
>> and the AUTH attribute.
>> {ed note: I wanted to give an example, but I can't seem to.
>> I read as far back as DOI-04, but didn't see any changes... unless
>> the issus is that the Auth(HMAC-MD5) wasn't being sent???}
>>
>> 6. Some vendors used old isakmp-08 certificate request format, but the
>>data
>> attrbute used in the payload was incorrectly formatted (or missing).
>> {ed note: isakmp-09 was not publically available for the interop}
>>
>> 7. Some vendors did not like getting a key hash payload in rsa encryption
>> mode.
>>
>> 8. Some vendors were discarding entire ISAKMP packet when an unknown
>> notify payload was received. Only the single payload should be
>> discarded.
>>
>> 9. 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).
>>
>> 10. Some vendors did not like receiving certificate request payloads at any
>> time.
>>
>> 11. Some vendors did not like ISAKMP packet to be padded to a multiple of 4
>> bytes.
>>
>> 12. Some vendors expected to see client ID's in phase 2. This caused
>> quick mode to complete, but fail to install the SA properly.
>>
>> 13. Some vendors were not prepared to receive INITIAL-CONTACT notifies.
>>This
>> caused premature termination of the negotiation. Speculation that
>> some vendors may terminate on any unknown status-level information
>> notifications.
>>
>> 14. (Relating to #5, and perhaps answering my question)
>> 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 the Transform type
>> and the Authentication Algorithm attribute.
>> {ed: I must say that I'm not clear why we have two definitions here, and
>> I didn't find anything obvious by grepping my archives. If someone
>> tells me what month to look in...}
>>
>> {ed: I received nothing about any wire level transform level issues. This
>>is
>> probably good.}
>>
>> :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON
>> Michael Richardson |Network and security consulting and contract
>>programming
>> Personal: <A
>>HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">
>>m
>>cr@sandelman.ottawa.on.ca</A>. PGP key available.
>> Corporate: <A
>>HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</
>>A
>>>.
>>
>>
>>
>>
>>
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: 2.6.3ia
>>Charset: latin1
>>Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
>>
>>iQB1AwUBNQ9HH9iXVu0RiA21AQF+KAL+PWlBkRYOCwoXtbm1nW73nbKP+fTS813e
>>k8JG6Hyhe9tgmI6gU57m1PiPL5GZAdZzyC1PCGFSfdsbnAT93kkuBgo8eBgD8ZcP
>>cnJhJtHdRexpCZXsL5cYQ5bwqc464dOT
>>=0OuF
>>-----END PGP SIGNATURE-----