Kalyani Garigipati (kagarigi) writes: > Please validate if the following is true. > > Apart form Notify, DELETE, Vendor ID, CERT, CERTREQ, PROPOSAL, TRANFORM, > TSi and TSr all other payloads like SA1, SA2, IDi, IDr, KE, NONCE, > DELETE, AUTH, CONFIG, ENCRYPT should not be sent as multiple payloads.
Encrypt MUST be last packet, thus that also limits that there can be only one of such payloads in packet. For all others there is no explicit restriction that they cannot appear multiple times, but on the other hand the exchanges we now have do not ever put multiple SA, KE, IDi, IDr, AUTH, Ni/Nr (Nonce), TSi, TSr, or EAP payloads in the same packet. For CERT, CERTREQ, N (notify), D (delete), V (Vendor ID) it is clear that there CAN be multiple payloads of those types in same packet. For CP (configuration payload) it not clear whether there can be multiple or not, but I would expect most implementations expect to find only one, and will only use one. In future someone might make extensions which puts multiple CP payloads in same packet, but currently we do not have such. > Like if we get packet as HDR, SA1, SA1, KE, N > We should reject it ? Best would be to check first the exchange type, and check out that all mandatory payloads which are required for that are there. Also when parsing it should be quite ok to stop parsing immediately when you see for example 2nd encrypted payload, or 2nd SA payload (In IKEv1 we could have multiple SA payloads in one quick mode exchange, as there was option to create multiple IPsec SAs at once, but that is not allowed in IKEv2). After that parsing all optional payloads (notifies, vendor id payloads, etc). Then the question is whether there is any need to check if there is any extra payloads in the exchange, and if such is found what to do (lets say someone puts configuration payload as part of the IKE_SA_INIT instead of IKE_AUTH). For this there is no clear answer, if you want to be able to work with future extensions without breaking when seeing them, best might be just ignore them. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
