Subject: [Ipsec] Is this a good use of the INVALID_KE_PAYLOAD notification?

From: "Christian Kaas-Petersen \(AH/LMD\)" <[email-masked]>
Date: Thu, 3 May 2007 09:58:44 +0200

Let host A initiate the following IKEv2 exchange (either an
IKE_SA_INIT or CREATE_CHILD_SA exchange) with host Z.  For this
example, only the SA and KE payloads are relevant.

     host A                          host Z

              ---------------->
              IKEv2 Request containing
              SA payload with two proposals
                    proposal 1: ... D-H = 1 ...
                    proposal 2: ... D-H = 2 ...
              KE payload with DH keyhalf using D-H = 1
                              (because proposal 1
                              is host A's preferred proposal)

             <----------------
             IKEv2 Response containing
             INVALID_KE_PAYLOAD notification specifying D-H = 5

How shall host A interpret the response?

Interpretation 1: Host Z did not indicate a D-H group among the
                  proposals submitted.  Thus host A has
                  no hope that retransmitting with another
                  KE payload will bring success, therefore
                  exchange has failed.

Interpretation 2: Host Z has by naming a new D-H group
                  indicated, that host A should come up with
                  a stronger set of proposals.  This could
                  be useful, if the number of proposals
                  is huge such that host A sort of
                  sematically fragment the total set
                  of proposals in order to keep packet size
                  low.

Is there a right answer? Are both valid?  Are both useful?

Christian

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Martin Willi <[email-masked]>
Date: Thu, 03 May 2007 10:45:47 +0200

Hi,

>                   KE payload will bring success, therefore

I think host Z should not respond with INVALID_KE_PAYLOAD, but with
NO_PROPOSAL_CHOSEN. INVALID_KE_PAYLOAD may only choose another group
included in the proposal (1 or 2).
But if Z does so, the negotiation fails.

>                   of proposals in order to keep packet size

A host Z should not return a INVALID_KE_PAYLOAD if it doesn't like the
proposals, it sends NO_PROPOSAL_CHOSEN. So this "give-me-more-proposals-
to-select-from" approach is not interoperable.

Best regards
Martin