Subject: [AAA-WG]: Any benefits for using Diameter message format in UNI interface?

From: <[email-masked]>
Date: Mon, 28 Apr 2003 14:31:25 +0300

Hi,

We are discussing in PANA WG about the possibility to use Diameter message formatting between PaC and PAA (PAA is generally seen as the AAA Client for the backend AAA). PANA's request/response (see IKEv2 exchanges) style transport together with Diameter message formatting would open up possibilities to extend Diameter apps to work with mobile clients too. Anyway, PANA deals with authentication and authorization which makes Diameter kind of suitable choice for message formatting.

PANA could specify new command codes (PANA messages) and AVPs when needed. Do you see any drawbacks with this approach? IANA considerations are of course needed. One possibility could be to preserve a new Application Id for PANA. For PANA it doesn't give any benefit, except the compatibility. Another choice would just mark the App-Id field reserved in PANA spec. Third possibility is to use the App-Id field in PANA scope and separate it from the Diameter App-Ids.

Currently Application-Id field is seen as an extra field for the PANA header. If we remove that, compatibility with Diameter is lost, though. PANA also uses two sequence numbers in place of Hop-by-Hop Id and End-to-End Ids which makes PANA a bit different too.

 -- 

Another question/proposal. Would there be interest to have an extended support for Diameter over UDP (between mobile client and network), if PANA doesn't go into this direction. Message transport would be request/response style exchanges like in IKEv2 and message formatting Diameter. Sequence numbering similar to IKEv2, which also suits well with Diameter Hop-by-Hop and End-to-End Ids. The result would be to provide transport for Diameter Applications over UDP (connectionless). This would enable roaming clients to be part of apps, because of the sessionless kind of nature of the UDP (no IP binding needed nor handshakes like in TCP or SCTP). IKEv2 could be used to bootstrap an SA between client and the network (optionally one way or mutual authentication too) and to protect the integrity. Together with possible session resumption capabilities and confidentiality protection this framework becomes quite an interesting platform for apps. Let me hear your comments.

Tnx,
- Dan