diameter sip application ietf 64 vancouver, 6-11 november, 2005 e-mail: [email protected]

11
Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: [email protected]

Upload: toby-holmes

Post on 03-Jan-2016

213 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Diameter SIP application

IETF 64Vancouver, 6-11 November, 2005

e-mail: [email protected]

Page 2: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Status draft-ietf-aaa-diameter-sip-app-10.txt passed

the 3rd WG Last Call in October 2005. New requirements have been coming during each

previous WGLC After the 3rd WGLC new issues were raised, mainly

due to compatibility with the 3GPP Diameter application for the Cx interface.

All issues are tracked at: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/

Page 3: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 49: Required Authentication parameters (1)

Use case: Nonces are generated

in the Diameter client Check for final

authentication also takes place in the Diameter client.

The Diameter client sends the generated nonce to the Diameter server in MAR

+--------+ +--------+ |Diameter| | SIP | | server | | server | +--------+ +--------+ | | | | 1. SIP INVITE | ----------------------------------->| | | 2. 407 Proxy Authentication Required) | <-----------------------------------| | | 3. SIP INVITE | ----------------------------------->| | 4. MAR | |<------------------| | 5. MAA | |------------------>| 6. SIP INVITE | |----------------> | | 8. SIP 200 (OK) 8. SIP 200 (OK) |<---------------- <-----------------------------------| | |

Page 4: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 49: Required Authentication parameters (2)

Optimization 1: MAA command includes a SIP-Authenticate AVP

which mandates to include a nonce (Digest-Nonce AVP).

Since the nonce has been previously generated in the Diameter client, there is not need to repeat this AVP anymore.

Proposal: make Digest-Nonce AVP optional in SIP-Authenticate AVP

Page 5: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 49: Required Authentication parameters (3)

Optimization 2: MAR command includes a SIP-

Authorization AVP which mandates to include Digest-URI and Digest-Response AVPs.

The Diameter server does not really need Digest-URI or Digest-Response

Proposal: Make Digest-URI and Digest-Response AVP optional in the SIP-authorization AVP

Page 6: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 49: Required Authentication parameters (4)

Optimization 3 SIP-Authentication-Info AVP mandates the

inclusion of a Digest-Nextnonce AVP Since nonces are generated in the

Diameter client, there is no point in the Diameter server including a Digest-Nextnonce AVP

Proposal: make Digest-Nextnonce AVP in the SIP-Authentication-Info AVP

Page 7: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 50: User-Data AVP in PPR

PPR mandates to include a User-Data AVP However, there is a use case where the

User-Data AVP is not updated, but the SIP-Accounting-Information AVP instead.

Proposal: Make User-Data AVP optional, modify the explanatory text accordingly.

Page 8: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 51: Result-Code AVP Message formats are not open to vendor

extensions because all commands mandate Auth-Application-ID AVP. Complaint: can’t use

Experimental-Result/Experimental-Result-Code AVPs

But Diameter SIP application is not a vendor specific application, so commands MUST contain a Result-Code AVP

Proposal: do nothing

Page 9: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 52: Auth-Application-ID AVP Message formats are not open to vendor

extensions because all commands mandate Auth-Application-ID AVP. Complaint: Vendor-Specific-Application-ID

AVP cannot be used in a command But Diameter SIP application is not a vendor

specific application, so commands MUST contain Auth-Application-ID.

Proposal: do nothing.

Page 10: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 53: MAR processing The user is not authenticated until the MAA

command is received, but the MAR processing assumes it is. Authentication flag is set if the SIP-Server AVP

contains a different value than in the past. The flag is cleared if the stored value matches

the SIP-Server AVP However, the user is not completely

authenticated at this stage (MAR/MAA). Proposal: the flag must be cleared when

processing the SAR/SAA commands instead

Page 11: Diameter SIP application IETF 64 Vancouver, 6-11 November, 2005 e-mail: miguel.an.garcia@nokia.com

Issue 54: Auth-Application-ID AVP in UAR command The syntax of the UAR command defines the Auth-

Application-ID as a fixed AVP (i.e., syntax within <> brackets), but the rest of the commands list it as a mandatory AVP (i.e., syntax within {} brackets).

No specific guidance is provided in RFC 3588, but in all commands the Auth-Application-ID appears as mandatory AVP

Proposal: be consistent with other commands and change< Auth-Application-Id >

with { Auth-Application-Id }

in the syntax of the UAR command