Subject: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-app-02

From: "Beck01, Wolfgang" <[email-masked]>
Date: Fri, 30 Apr 2004 10:29:50 +0200

Hello,

p 12, section 5.3

step 12: "SIP server 2 will validate the credentials.."
How can the SIP server do this? It has asked for authentication
parameters in steps 5 and 6, but it doesn't have the user's password.

p 32, section 7.7
"The SIP-Method AVP MUST include the SIP method name of the SIP
request that triggered this Diameter MAR message.

The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP
indicates the intended Address-of-Record of the SIP request. "

Why are SIP-Method and SIP-AOR mandatory? I would have expected a
mandatory Contact: or From: URI, or some other information about
the user requesting authentication.

p 48, typo 'Digest-Relam'

Regards,

Wolfgang

--
Wolfgang Beck
T-Systems
Internet Netzplattformen
Am Kavalleriesand 3
64295 Darmstadt

---

From: MCarmen <[email-masked]>
Date: Fri, 30 Apr 2004 15:54:21 +0200

Hi all,

Just a question on RFC3588. In the CER/CEA chapter it is said:

" When two Diameter peers establish a transport connection, they MUST 
exchange the Capabilities Exchange messages, as specified in the peer 
state machine (see Section 5.6).  This message allows the discovery of a 
peer's identity and its capabilities (protocol version number, supported 
Diameter applications, security mechanisms, etc.) "

Is it possible to exchange again the Capabilities Exchange messages once 
the connection is already  established to modify my capabilities?

thanks,
MCarmen

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 30 Apr 2004 08:34:18 -0700 (PDT)

I don't think this makes sense.

The peers announce all their capabilities in the CER/CEA and this is
typically something that does not change on the fly.  In what scenario
would the fundamental capabilities of the peers change in mid-connection?
Upgrade on the fly?

In a situation where firmware is upgraded, connections will
typically go down and the peer will announce its new capabilities and
negotiate them within the CER/CEA.

Even if a peer is upgraded on the fly without going down, the right answer
is probably to bring up other connections, negotiate CER/CEA, and if they
are upgraded, drop the existing connections.  This could be an issue with
RFC 3588 because Diameter only allows one connection at a time between two
peers.  So I think you'd need to bring down a connection between two peers
to re-negotiate CER/CEA between them.