D108 IKEv2 Payloads

From: Jari Arkko
Subject: [Mobike] design draft issue: ikev2 payloads
Date: Wed, 21 Dec 2005 12:53:31 +0200

|    Some implementations might have problems parsing more
|    than certain number of IKEv2 payloads, but if the sender sends them
|    in the most preferred first, the receiver can only use the first
|    addresses, it was willing to parse.


Hmm... the IKEv2 spec seems to say that you MUST
be able to reject Critical=1 payloads that you don't
recognize. This seems to imply that you must go through
all the payloads, or am I missing something?

From: Tero Kivinen
Subject: [Mobike]  D108 design draft issue: ikev2 payloads
Date: Tue, 3 Jan 2006 19:01:30 +0200

Jari Arkko writes:
| |    Some implementations might have problems parsing more
| |    than certain number of IKEv2 payloads, but if the sender sends them
| |    in the most preferred first, the receiver can only use the first
| |    addresses, it was willing to parse.
| 
| 
| Hmm... the IKEv2 spec seems to say that you MUST
| be able to reject Critical=1 payloads that you don't
| recognize. This seems to imply that you must go through
| all the payloads, or am I missing something?

You need to go through all payloads to check the critical bit and that
the payload chaining is correct. On the other hand you do not need to
parse 256 status notifications or 100 certificates the other end
decided to send to you. You only need to parse first certificate
payload, as it is end entity certificate, and you can ignore the rest,
and fetch the certificates from some other source if you want.

I do know there was some IKEv1 implementations that refused to parse
some of our packets as they did have fixed limit of number of
certificate payloads they accepted, or they had fixed limit of number
of SA proposal you could have etc. I wouldn't be suprised that there
would be implementation out that has fixed number of status
notifications it will parse or decode.