Subject: RE: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt

From: <[email-masked]>
Date: Mon, 14 Jun 2004 14:50:18 +0300

Hi,

Would it simplify things if the messages copied straight 
from NASREQ (RAR/RAA, STR/STA, ASR/ASA and also ACR/ACA) 
would use Auth-Application-Id 1 (NASREQ) instead?

(This way e.g. a translation agent would not need to keep
track of whether a PPP session was originally authenticated 
with CHAP or EAP... but then again, I have not considered
this case thoroughly.)

I'm also wondering whether copying the ABNF for ACR/ACA
is necessary... (presumably, some later document that e.g. 
defines a new WLAN-specific AVP/attribute would not copy 
the whole ABNF of all messages; just saying in which messages 
the AVP can be included would be enough.)

Best regards,
Pasi

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, June 03, 2004 10:36 AM
> To: Bernard Aboba
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt
> 
> 
> Bernard Aboba wrote:
> 
> > This document does not define the ABNF for use with the 
> ASR, ASA, RAR,
> > RAA, STR, or STA commands.  This is probably very similar 
> to the ABNFs
> > used with NASREQ, in which case a reference to [NASREQ] may suffice.
> 
> Yes. The document does not even mention these commands
> currently. Perhaps a new subsection somewhere under
> current Section 3. Also, accounting request ABNF needs
> to be defined, and it has one difference to the NASREQ
> ABNF, the Accounting-EAP-Auth-Method AVP.
> 
> How about this:
> 
>    3.3 Base and NASREQ Commands
> 
>    Where the NASREQ AA-Request (AAR) or AA-Answer (AAA)
>    commands are used for authorization in conjunction with
>    EAP (see Section 2.3.3), the Auth-Application-Id AVP
>    MUST be set to 1 (NASREQ), and the rules and command
>    ABNF defined in [Diameter NASREQ] MUST be followed.
> 
>    Where the Re-Auth-Request (RAR), Re-Auth-Answer (RAA),
>    Session-Termination-Request (STR), 
> Session-Termination-Answer (STA),
>    Abort-Session-Request (ASR) and Abort-Session-Answer (ASA)
>    are used in conjunction with EAP, the Auth-Application-Id
>    AVP MUST be set to <To Be Allocated By IANA> (EAP). Nevertheless,
>    the same rules and command ABNF defined in [Diameter NASREQ]
>    MUST be followed even in this case.
> 
>    3.4. Accounting Commands
> 
>    The Accounting-Request (ACR) message [Base], is sent by the NAS, to
>    report it's session information to a target server downstream.
> 
>    One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
>    MUST be present.  If the Vendor-Specific-Application-Id grouped AVP
>    is present, it must have an Acct-Application-Id inside.
>    [NOTE: This text is copied from NASREQ. But I don't understand
>    how the NASREQ or EAP application can have a VSAID.]
> 
>    The AVPs listed in the Base MUST be assumed to be present as
>    approriate.  NASREQ and EAP specific accounting AVPs, 
> SHOULD be present
>    as described in [Diameter NASREQ] and the rest of this 
> specification.
> 
>     Message Format
> 
>        <AC-Request> ::= < Diameter Header: 271, REQ, PXY >
>                        < Session-Id >
>                        { Origin-Host }
>                        { Origin-Realm }
>                        { Destination-Realm }
>                        { Accounting-Record-Type }
>                        { Accounting-Record-Number }
>                        [ Acct-Application-Id ]
>                        [ Vendor-Specific-Application-Id ]
>                        [ User-Name ]
>                        [ Accounting-Sub-Session-Id ]
>                        [ Accounting-Session-Id ]
>                        [ Acct-Multi-Session-Id ]
>                        [ Origin-State-Id ]
>                        [ Destination-Host ]
>                        [ Event-Timestamp ]
>                        [ Acct-Delay-Time ]
>                        [ NAS-Identifier ]
>                        [ NAS-IP-Address ]
>                        [ NAS-IPv6-Address ]
>                        [ NAS-Port ]
>                        [ NAS-Port-Id ]
>                        [ NAS-Port-Type ]
>                      * [ Class ]
>                        [ Service-Type ]
>                        [ Termination-Cause ]
>                        [ Accounting-Input-Octets ]
>                        [ Accounting-Input-Packets ]
>                        [ Accounting-Output-Octets ]
>                        [ Accounting-Output-Packets ]
>                        [ Acct-Authentic ]
>                        [ Accounting-Auth-Method ]
>                        [ Acct-Link-Count ]
>                        [ Acct-Session-Time ]
>                        [ Acct-Tunnel-Connection ]
>                        [ Acct-Tunnel-Packets-Lost ]
>                        [ Callback-Id ]
>                        [ Callback-Number ]
>                        [ Called-Station-Id ]
>                        [ Calling-Station-Id ]
>                      * [ Connection-Info ]
>                        [ Originating-Line-Info ]
>                        [ Authorization-Lifetime ]
>                        [ Session-Timeout ]
>                        [ Idle-Timeout ]
>                        [ Port-Limit ]
>                        [ Accounting-Realtime-Required ]
>                        [ Acct-Interim-Interval ]
>                      * [ Filter-Id ]
>                      * [ NAS-Filter-Rule ]
>                        [ Framed-AppleTalk-Link ]
>                        [ Framed-AppleTalk-Network ]
>                        [ Framed-AppleTalk-Zone ]
>                        [ Framed-Compression ]
>                        [ Framed-Interface-Id ]
>                        [ Framed-IP-Address ]
>                        [ Framed-IP-Netmask ]
>                      * [ Framed-IPv6-Prefix ]
>                        [ Framed-IPv6-Pool ]
>                      * [ Framed-IPv6-Route ]
>                        [ Framed-IPX-Network ]
>                        [ Framed-MTU ]
>                        [ Framed-Pool ]
>                        [ Framed-Protocol ]
>                      * [ Framed-Route ]
>                        [ Framed-Routing ]
>                      * [ Login-IP-Host ]
>                      * [ Login-IPv6-Host ]
>                        [ Login-LAT-Group ]
>                        [ Login-LAT-Node ]
>                        [ Login-LAT-Port ]
>                        [ Login-LAT-Service ]
>                        [ Login-Service ]
>                        [ Login-TCP-Port ]
>                      * [ Accounting-EAP-Auth-Method ]
>                      * [ Tunneling ]
>                      * [ Proxy-Info ]
>                      * [ Route-Record ]
>                      * [ AVP ]
> 
>     The Accounting-Answer (ACA) message [Base], is used to 
> acknowledge an
>     Accounting-Request command.  The Accounting-Answer 
> command contains
>     the same Session-Id as the Request.  If the Accounting- 
> Request was
>     protected by end-to-end security, then the corresponding 
> ACA message
>     MUST be protected by end-to-end security.
> 
>     Only the target Diameter Server, or home Diameter Server, SHOULD
>     respond with the Accounting-Answer command.
> 
>     One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
>     MUST be present, as was in the request.
> 
>     The AVPs listed in the Base MUST be assumed to be present as
>     approriate.  NASREQ and EAP specific accounting AVPs, 
> SHOULD be present
>     as described in [Diameter NASREQ] and the rest of this 
> specification.
> 
>     Message Format
> 
>        <AC-Answer> ::= < Diameter Header: 271, PXY >
>                        < Session-Id >
>                        { Result-Code }
>                        { Origin-Host }
>                        { Origin-Realm }
>                        { Accounting-Record-Type }
>                        { Accounting-Record-Number }
>                        [ Acct-Application-Id ]
>                        [ Vendor-Specific-Application-Id ]
>                        [ User-Name ]
>                        [ Accounting-Sub-Session-Id ]
>                        [ Accounting-Session-Id ]
>                        [ Acct-Multi-Session-Id ]
>                        [ Event-Timestamp ]
>                        [ Error-Reporting-Host ]
>                        [ Origin-State-Id ]
>                        [ NAS-Identifier ]
>                        [ NAS-IP-Address ]
>                        [ NAS-IPv6-Address ]
>                        [ NAS-Port ]
>                        [ NAS-Port-Id ]
>                        [ NAS-Port-Type ]
>                        [ Service-Type ]
>                        [ Termination-Cause ]
>                        [ Accounting-Realtime-Required ]
>                        [ Acct-Interim-Interval ]
>                      * [ Class ]
>                      * [ Proxy-Info ]
>                      * [ Route-Record ]
>                      * [ AVP ]
> 
> > I believe that this application shares many of the same 
> RADIUS/Diameter
> > translation considerations as NASREQ Section 9.  It should probably
> > explicitly state this, particularly as regards the RADIUS
> > Dynamic Authorization considerations described in Sections 9.1.1 and
> > 9.2.1 of NASREQ.
> 
> Perhaps this is sufficient:
> 
>     Section 9 of [NASREQ] describes basic guidelines that translation
>     agents may follow when translating between RADIUS and Diameter
>     protocols. This section gives additional guidelines for 
> the Diameter
>     EAP application.
> 
> =>
> 
>     Section 9 of [NASREQ] describes basic guidelines for translation
>     agents that translate between RADIUS and Diameter protocols.
>     These guidelines SHOULD be followed for EAP application as well,
>     with some additional guidelines given in this section.
> 
> --Jari
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Jun 2004 07:42:11 -0700 (PDT)

My understanding of RFC 3588 is that if you only add *optional* AVPs, then
the Application-ID does not change.  So if the NASREQ ABNF is valid for a
command, then you can (and should) use an Application-Id of NASREQ.

Note that an EAP AVP cannot be optional, so commands using EAP
payloads need the Diameter EAP Application ID.  However, commands that do
not use EAP payloads do not need (and in my opinion should not use) the
EAP Application-ID.

I think this approach makes sense because it follows the "Principle of
Least Astonishment" -- if the usage is indistinguishable from
NASREQ, why should the application-ID change?

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jun 2004 18:11:14 +0300

> NASREQ, why should the application-ID change?

If the application ID is NASREQ, there might be another type
of astonishment: a session is opened via EAP application and
then suddenly deleted via NASREQ. Hmm...

But I haven't read Pasi's e-mail yet, will do so later today...

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Jun 2004 08:28:30 -0700 (PDT)

> then suddenly deleted via NASREQ. Hmm...

The goal of the language in RFC 3588 was to avoid creating unnecessary
interoperability problems.  A given Diameter agent might be only be able
to handle certain Application-IDs.  For example, a Diameter/RADIUS gateway
may be built to handle unsolicited deletion or change of authorization using
the NASREQ Application-ID, according to the guidance in [NASREQ].  The EAP
application uses the same unsolicited change of
authorization/deletion commands with the same ABNF as NASREQ.  Changing
the Application-Id would break interoperation with the RADIUS/Diameter
gateway with no benefits -- the gateway can only handle an Application-Id
of NASREQ for unsolicited operations.

So it seems to me that if an unsolicited operation conforms to the ABNF in
[NASREQ] then it should use an Application-Id of NASREQ -- since a
Diameter/RADIUS gateway is defined for those commands for that
Application-ID -- and for no other Application-ID.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jun 2004 22:22:14 +0300

> Application-ID -- and for no other Application-ID.

Ok.

--Jari