Subject: Re: [Dime] draft-ietf-dime-ikev2-psk-diameter open issues

From: "Cakulev, Violeta (Violeta)" <[email-masked]>
Date: Wed, 23 Feb 2011 13:03:40 -0600

All,
I have received no further comments on issue 1.

As for the issue 2, there were comments asking for solution 5 (described below).

Therefore, 04 of the draft is uploaded that addresses the issues below as follows:
1. Issue 1: no changes in 04.
2. Issue 2: Solution 5 is implemented.

Best regards,
-Violeta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sebastien Decugis
Sent: Tuesday, November 23, 2010 8:44 PM
To: [email-masked]
Subject: Re: [Dime] draft-ietf-dime-ikev2-psk-diameter open issues

Hello,

I think the solution to issue 1 is reasonable.

About issue 2, is there a reason why you are not considering a "solution 5" that was proposed during Beijing meeting, as follow:

Solution 5: Use Key-SPI AVP defined in draft-ietf-dime-local-keytran for the request. Use Key AVP in the answer. (you'll have to precise which AVPs must be present in this grouped AVP in the answer in you application, like for example Key-SPI AVP).

Best regards,
Sebastien.

Le 24/11/2010 04:22, Cakulev, Violeta (Violeta) a écrit :
> As discussed in Beijing meeting, there are 2 open issues. These open issues and their respective solutions are summarized below.
>
> ----------------------------------------------------------------------
> ------------------ Issue 1. Is there any need for Auth-Request-Type
> AVP in the request if only Authorize-Only (value 2) is used in this application? What should be the behavior of the receiver if the Auth-Request-Type AVP is set to the value 1 or 3, which are valid values? What is the error code send back to the sender?
>
> Solution to issue 1: Keep Auth-Request-Type AVP in the request with only Authorize-Only (value 2) allowed. If values 1 or 3 are received send Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE and include the Auth-Request-AVP in the Failed-AVP AVP. DIAMETER_INVALID_AVP_VALUE is a permanent failure, therefore the peer is informed that the request failed, and should not be attempted again. Values 1 and 3 are valid values in Diameter based protocol, however they are invalid values in this I-D, therefore there are no problems to send DIAMETER_INVALID_AVP_VALUE if 1 or 3 are received.
> ----------------------------------------------------------------------
> ------------------
>
> Issue 2: When IKEv2 Server requests the key it may use SPI to help AAA determine which key needs to be returned. How is this SPI transported to AAA?
> This issue has multiple solutions. Some of the solutions are outlined below. Interested parties are invited to indicate preferred solution.
>
> Solution 1: SPI is contained in Key AVP specified in draft-ietf-dime-local-keytran. Key AVP sent in the request contains only SPI AVP. In this case, draft-ietf-dime-local-keytran is modified such that Keying-Material AVP is optional AVP.
>
> Solution 2: SPI is contained in Key AVP specified in draft-ietf-dime-local-keytran. Key AVP sent in the request contains both Keying-Material AVP and SPI AVP. Keying-Material AVP is populated with all 0s and/or is ignored by AAA. In this case, no changes to draft-ietf-dime-local-keytran are needed.
>
> Solution 3: Do not use draft-ietf-dime-local-keytran and specify all AVPs in this I-D.
>
> Solution 4: Specify SPI AVP in this I-D and send it separately in the request. Use Key AVP specified in draft-ietf-dime-local-keytran in the response.
> ----------------------------------------------------------------------
> -------------------
>
>
> Best regards,
> -Violeta
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime