Issue 201: MIP-FA-to-MN-SPI and co-located
servers
Submitter name: Mark Eklund
Submitter email address:
meklund@diameter.org
Date first submitted: 12-Oct-01
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00101.html
Document:
mobileip
Comment type: T
Priority: 1
Section: 6.0
Rationale/Explanation of issue:
This is a sub-issue of the issue,
"Issue: Required AVPs in grouped
key AVPs" submitted earlier by me that
requests changing to use the
Key ABNA as listed in the reference above.
The value for the MIP-FA-to-MN-SPI key is contained in the
registration request sent by the MN (and placed in the
MIP-Reg-Request
by the FA). The HA normally extracts this and sends
it back to the AAAH as
the MIP-FA-to-MN-SPI. The AAAH can then
place that in the MIP-FA-to-MN-Key
and sent back to the FA.
A problem happens with a co-located server.
When the AAAF gets an
AMR and the MN-to-FA key was requested, it sends an
AMA back to the
FA that contains the MIP-FA-to-MN-Key and the
MIP-MN-to-FA-Key. The
problem is that the AAAF doesn't speak mobileip and
can't
extract the MIP-FA-to-MN-SPI from the registration request.
Requested change:
The currently suggested ABNF for the
MIP-FA-to-MN-Key and the
MIP-MN-to-FA-Key is
MIP-FA-to-MN-Key ::=
< AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
{ MIP-Key-Lifetime }
* [ AVP ]
MIP-MN-to-FA-Key ::= < AVP Header: 325 >
{ MIP-Algorithm-Type
}
{ MIP-Key-Material }
{ MIP-Key-Lifetime }
{ AAA-SPI }
* [ AVP
]
Either make the MIP-FA-to-MN-SPI in the MIP-FA-to-MN-Key optional or
only require that the MIP-MN-to-FA-Key be sent back when the server
is
co-located and add the MIP-Session-Key as an optional AVP. I.E.
MIP-MN-to-FA-Key ::= < AVP Header: 325 >
{ MIP-Algorithm-Type
}
{ MIP-Key-Material }
{ MIP-Key-Lifetime }
{ AAA-SPI }
[
MIP-Session-Key ]
* [ AVP ]
Issue 202: Alternatives to the Command Code ABNF
specification
Submitter name: Jaakko Rajaniemi
Submitter email
address: jaakko.rajaniemi@nokia.com
Date first submitted: 2001-10-18
Document: base
Comment type: T
Priority: 1
Section: 3.2
Rationale/Explanation of issue:
The section 3.2 "Command Code ABNF
specification" contains the ABNF
specification which must be followed when
contructing Diameter Command
Codes. It does not contain a possibility to use
the alternatives (see
RFC2243, section 3.2) when defining the AVPs included
into the commands.
This is very restrictive and does not allow enough
flexibility when defining
command codes and therefore it is proposed that
the alternatives is
included.
Requested change:
Include
following description to the avp-spec in the section 3.2:
avp-spec =
diameter-name *("/" diameter-name)
; The avp-spec has to be an AVP Name,
; defined in the base or extended Diameter
; specifications. The
avp-spec may contain AVP Names
; which are alternatives, see RFC 2234
section 3.2.
Issue 203: MIP-FA-to-HA being added to the AMA by
the AAAF
Submitter name: Mark Eklund
Submitter email address:
meklund@cisco.com
Date first submitted: 25-Oct-01
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00031.html
Document:
mobileip
Comment type: Technical
Priority: 1
Section: 2.4, 5.3, 8.1
Rationale/Explanation of issue:
When the HA is in the foreign
network and a FA-HA key is requested,
the AAAF generates the key. The AAAF
is then responsible for adding
the MIP-FA-to-HA Key to the AMA. This means
that the AAAF must
maintain a list containing all MIP-FA-to-HA Key AVPs and
their
matching Accounting-Multi-Session-Id AVPs. When each AMA is received,
the AAAF must then consult the list and when it finds a matching
Accounting-Multi-Session-Id, add the MIP-FA-to-HA Key AVP to the AMA.
Requested change:
Instead of requiring the AAAF to add the
MIP-FA-to-HA Key AVP to the
AMA, send the MIP-FA-to-HA Key back in the HAA.
The AAAH then can
move the MIP-FA-to-HA Key from the HAA to the AMA.
Add [MIP-FA-to-HA-Key] to the HAR ABNF in section 2.4.
Change
MIP-Feature-Vector column HAR = 0-1 to section 8.1
Change MIP-FA-to-HA-Key
column HAA = 0-1 to section 8.1
Change the final paragraph of section
5.3 to
Upon receipt of the HAA, the Diameter server responsible for key
allocation creates the MIP-FA-to-HA Key AVP, using the SPI in the
MIP-FA-to-HA-SPI. If the key is generated at the AAAF, it adds the
MIP-FA-to-HA Key AVP to the HAA and sends it to the AAAH.
Depending upon
where the HA was located the AAAH either generates the
MIP-FA-to-HA Key AVP
itself or extracts the AVP from the HAA sent
by the AAAF. The AAAH adds the
MIP-FA-to-HA Key to the AMA.
Issue 204: How to handle CER from unknown peer
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: 5.3,
7.1
Rationale/Explanation of issue:
If a CER is received from an
unknown peer, the draft doesn't really specify
what should be done. A new
Result-Code will handle this case (and the
necessary text in 5.3.
Issue 205: Should AVPs be ordered?
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 3
Section: 3.2
Rationale/Explanation of issue:
The base protocol spec command code
ABNF doesn't specify that mandatory
AVPs don't necessarily need to appear
before the optional ones. Add a
sentence making this clearer.
Issue 206: ABNF of non-proxiable commands
incorrect
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section:
various
Rationale/Explanation of issue:
Some non-proxyable command
code's ABNFs include the Destination-Host and
Destination-Realm AVPs, which
is invalid according to the definition of
these AVPs. The ABNFs need to be
cleaned up.
Issue 207: AAA URI inconsistent
Submitter
name: Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: various
Rationale/Explanation of issue:
Some examples of the URI in the spec
does not include the aaa://
prefix. Add it to the examples.
The ABNF
definition doesn't include the scheme name (aaa://). Add
that as well.
Issue 208: Peer State Machine incorrect in case of
election
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: 5.6,
7.1
Rationale/Explanation of issue:
The last state machine statement
is incorrect.
Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open
I-Rcv-DPR I-Snd-DPA, R-Open
R-Snd-CEA
I-Rcv-CEA R-Snd-DPR I-Open
If a CEA is returned with the proper error code, there is no reason
to send a DPR. Add the Result-Code value, and remove the DPR here.
Issue 209: Authorization-Lifetime
inconsistency
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base, MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
In the base draft, the
Authorization-Lifetime set to 0 means immediate
re-auth. In the MIP draft 0
means infinity. Fix the MIP draft to be
consistent with the base draft.
Issue 210: Session-Timeout ABNF/Table
inconsistency
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base, MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
In the MIP draft, the use of the
Session-Timeout in the command code
ABNFs in inconsistent with the table.
Issue 211: When should Destination-Host be present
in HAR?
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
In the MIP draft, it isn't really
clear when the Destination-Host should
be present in the HAR when the HA is
assigned in a foreign domain. The
text and figure need to be cleaned up.
Issue 212: How does the AAAH know the
Destination-Host of a previously assigned foreign HA?
Submitter name:
Pat Calhoun
Submitter email address: pcalhoun@bstormnetworks.com
Date
first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type:
Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Once a mobile has been assigned a home agent, if a subsequent HAR is to
be sent, a new AAAH has no way to map the IP address in the registration
request to a Destination-Host AVP of the Home Agent.
Fix
The
GNAIE ID is being updated to reflect comments of the IESG. In this
document
we will specify that the HA may include its NAI in the
Registration Reply,
and if so, the mobile node must include the same extension
in subsequent
registration requests. This will require some Mobile IP WG
involvement.
Issue 213: MN-AAA SPI must be included in the HAR
message
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
The Home Agent needs to have access
to the MN-AAA SPI in order to create
the Mobile AAA key extensions. This
information is not sent by the AAAH
to the home agent. Therefore the AAAH
must include the MIP-MN-AAA-SPI
AVP in the HAR to the HA.
Issue 214: Unknown-User Result-Code provides too
much info
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: 7.1
Rationale/Explanation of issue:
Some text should be provided in the
Result-Code value to state that
an alternative is to use
Authentication-Failure. It is felt that Unknown
User provides too much info,
and could lead to certain types of attacks.
Issue 215: Use of hmac-md5 is incorrect
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base, aaa-keys
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Need to make use that
the use of md5 and hmac-md5 is consistent across
both drafts. The latest
aaa-keys uses hmac-md5, but uses the incorrect
function prototype (it uses
hmac-md5 with a prefix+suffix mode).
Issue 216: Home Agent MUST support home address
allocation
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section: 1.2
Rationale/Explanation of issue:
The draft doesn't actually state
that the Home Agent MUST support
home address allocation, but the draft does
state that the AAAH MAY
do it. The lack of a MUST can cause interoperability
problems
Issue 217: typo in MIP section 3.2
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 4
Section: 3.2
Rationale/Explanation of issue:
In section 3.2, the term foreign
agent should read foreign domain.
Issue 218: ABNF/Table inconsistencies
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: all
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
In some drafts, there are
inconsistencies between the ABNF and the
command code tables at the end of
the spec.
Issue 219: AMA AVP issue when failure occurs
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
If the mobile is not authenticated
successfully (or some other error
occurs on AAAH), the ABNF requires some
AVPs that may not be available.
Issue 220: Not possible to dynamically update
capabilities
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
The draft does not allow a peer to
update its capabilities. Some folks
believe this is problematic when the
capabilities change over time.
Currently, it would require that the
transport be disconnected and
re-established.
Fix
Allow a
CER to be sent while in the open state.
Issue 221: Why require CMS to send its expected
AVPs?
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: cms
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Each Diameter application states
which AVPs should be encrypted and which
can be signed. Since this is
possible, why bother requiring that the DSAR
sender to include what AVPs it
expects to have signed/encrypted? Isn't
the AVP definition sufficient?
Resolution: The resolution to issues #221 and 279 was to remove the
expected-* AVPs
from CMS, and change the defintion of "MAY Encr" in both
base
and CMS. The agreed change in the CMS I-D is at the end
of section
3.1:
"Note: [BASE] includes the "MAY encr" column when describing AVPs.
For
the originator "MAY encr" as used in [BASE] means that if a
message
containing that AVP is to be sent via a proxy/agent (as opposed
to
directly) then the message MUST NOT be sent unless there is a
DSA
between the originator and the recipient OR the originator has
locally
trusted configuration that indicates that CMS need not be
used."
Issue 222: Routing within a domain
Submitter name: Pat Calhoun
Submitter email address:
pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: base
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
In a hierarchical network (meaning
that there are agents between the
access device and the destination) when
all peers are in the same
administrative domain, routing isn't guaranteed to
work.
Fix
When a hierarchy exists, a sub-domain should be used
(e.g. sub.domain.com).
Just add text to make this clear in the routing
section. With Longest-Match-
From-Right (already in the spec), this feature
works fine.
Issue 223: How does CMS work if the HA is unknown
and in foreign network
Submitter name: Pat Calhoun
Submitter email
address: pcalhoun@bstormnetworks.com
Date first submitted: 25-Oct-01
Reference:
Document: MIP
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
The Mobile IP extension
allows the foreign network to specify whether it
is willing to provide a
home agent. However, if the AAAH wants to setup a
DSA with the Home Agent,
how can it do that since it doesn't know the URI
of the HA.
Fix
When the AAAF states it is willing to allocate an HA in its domain, it
includes the URI in a new AVP, called Candidate-Home-Agent-Host.
Issue 224: Handling errors in the TCP stream
Submitter name: David Frascone
Submitter email address:
dave@frascone.com
Date first submitted: 25-Oct-01
Reference:
Document: Base
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Since TCP is stream oriented, an
error in the stream is completely
un-recoverable. Therefore, when an error
is detected in the stream, the
connection must be closed.
Errors can
be detected by reserved bits being set, avp lengths being
less than the size
of an AVP header, or greater than the diameter message
length.
There
was no input on whether or not to first send a response. Since
an error can
occur in a request or in an answer, I think closing the
connection without
sending a response is acceptable.
Issue 225: Specify Statefulness/Statelessness
Requirements
Submitter name: Bob Kopacz
Submitter email address:
BKopacz@InterlinkNetworks.com
Date first submitted: October 26,2001
Reference: None
Document: draft-ietf-aaa-diameter-mobileip-08-alpha01
Comment type: T
Priority: 1
Section: 1, 1.2, 1.4
Rationale/Explanation of issue:
The Mobile-IP Diameter draft is
fuzzy regarding
statefulness/statelessness requirements. Implementers are
left to infer
the requirements. Some people have inferred that an AAA home
server must
maintain session state, others have not made that inference.
Requested change:
Specify the statefulness/statelessness
requirements.
If it is true that maintaining session-state is not
required, then amend
the draft as follows:
1. Up front, somewhere in
the "Introduction" section, add the following
text:
"A AAA home
server which supports the Mobile-IP authentication
application MAY maintain
session-state or MAY be session-stateless. A
AAA foreign server which
supports the Mobile-IP authentication
application MAY maintain session-state
or MAY be session-stateless. AAA
redirect agents and AAA relay agents MUST
not maintain session-state.
AAA home and foreign servers, as well as AAA
proxies and relays, MUST
maintain transaction state."
2. Section 1.2
"Inter-Domain Mobile IP", says:
"During the creation of the HAR, the
AAAH MUST use a different session
identifier than the one used in the
AMR/AMA (see figure 2). Of
course, the AAAH MUST use the same session
identifier for all HARs
initiated on behalf of a given mobile node's
session."
Remove the 2nd sentence, which begins "Of course ...".
3. Section 1.2 "Inter-Domain Mobile IP", also says:
"For new
sessions, the AAAH MUST create an accounting session
identifier, which is
added to the Accounting-Multi-Session-Id AVP in
the HAR message sent to the
home agent."
Remove the phrase "For new sessions" from the first
sentence, so that
the text reads:
"The AAAH MUST create an
accounting session
identifier, which is added to the
Accounting-Multi-Session-Id AVP in
the HAR message sent to the home agent."
4 Section 1.4 "Allocation of Home Agent in Foreign Network", says"
"Figure 7 shows the message flows for a Mobile Node requesting to keep
the Home Agent assigned in Foreign network 1 when it moves to foreign
network 2. [...]. If the Mobile Node was
successfully authenticated the
AAAH checks for the Origin-Host and
the value of the Origin-Host of the
previous request. If a AAAH
deduces that the Mobile Node has moved to a new
realm, it must check
whether the Mobile can still use the previously
assigned Home Agent."
Change the sentence
"If the Mobile Node
was successfully authenticated the AAAH checks for
the Origin-Host and the
value of the Origin-Host of the previous
request."
to
"If
the Mobile Node was successfully authenticated, a session-stateful
AAAH
checks for the Origin-Host and the value of the Origin-Host of the
previous
request."
and add some text describing how a session-stateless AAAH
server deduces
that the Mobile Node has moved to a new foreign realm.
Issue 226: Server-Initiated Re-Auth in Diameter
MIPv4 not supported
Submitter name: Tony
Submitter email address:
tony.johansson@ericsson.com
Date first submitted: 26-Oct-01
Reference:
Document: MIP alpha -08
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
In section 8.3
Server-Initiated Re-Auth of the base protocol alpha -08
states the
following:
"Each Diameter application MUST state whether
service-initiated re-auth
is
supported, since some applications do not
allow for access devices to
prompt the user for re-auth."
However,
text is missing in the Diameter Mobile IPv4 application that
states that
this Diameter application can not deal with Server initiated
re-auth.
Issue 227: End to end identifier
Submitter
name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: 10/30/01
Reference: none
Document:
Base-08-alpha
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 3.0 Diameter Header
Rationale/Explanation of issue:
On
diameter servers which may utilize multiple (and potentially many)
processors, forcing the end-to-end identifier to be monotonically increased
by one for every message sent will probably cause scalability issues. This
is due to the fact that this identifier would have to be in shared memory,
and would require mutually exclusive access amongst all processors in order
to update the value, thus slowing down all other diameter processes waiting
to send a message.
Requested change:
In the sentence below,
remove the phrase "by incrementing the identifier by
one (1)." After all,
the method of ensuring the uniqueness of an identifer
is probably more of an
implementation issue anyway, right?
Senders of request or answer
messages MUST
insert a unique identifier on each message, by incrementing
the
identifier by one (1).
Issue 228: Remove Route_Record Avp in all the
Answer message
Submitter name: Michael Chen
Submitter email address:
cchen@erilab.com
Date first submitted: 5-Nov-01
Reference:
Document:
base-08-alpha2, mobileip-08-alpha2, nasreq-08-alpha2
Comment type: editorial
Priority: 1
Section: Base: 8.3.2 8.4.2 8.5.2 9.7.2
Mobileip 2.2 2.4
8.1
Nasreq 3.1.2 4.2.2 10.1
Rationale/Explanation of issue:
Only
Request Message include Route-Record Avp
Requested change:
Reove all
the Route-Record Avp in all the ABNF Answer message
(Base: RAA, STA, ASA,
ACA)
(Mobileip: AMA, HAA, Command Avp Table)
(Nasreq: AAA, DEA, Command
Avp Table)
Issue 229: Remove MIP-PEER-SPI AVP
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 5-Nov-01
Reference:
Document:
mobileip-08-alpha2
Comment type: editorial
Priority: 1
Section:
Mobileip 6.1 6.2 6.7
Rationale/Explanation of issue:
Reuse the AVP
which we have defined.
Requested change:
Remove 6.7 and replace
Mip-Peer-Spi with
Mip-FA-to-MN-Spi/Mip-FA-to-HA-Spi.
In other words, see
below
MIP-FA-to-MN-Key ::= < AVP Header: 326 >
{
MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [
AVP ]
MIP-FA-to-HA-Key ::= < AVP Header: 328 >
{
MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [
AVP ]
Issue 230: Add Mip-Key-Lifetime AVP to ABNF and
comand table
Submitter name: Michael Chen
Submitter email address:
cchen@erilab.com
Date first submitted: 5-Nov-01
Reference:
Document:
mobileip-08-alpha2
Comment type: editorial
Priority: 1
Section:
Mobileip 2.2 2.3 8.1
Rationale/Explanation of issue:
We need show
how to use MIP-Key-Lifetime Avp
Requested change:
Add [
MIP-Key-Lifetime ] to the ABNF of Home-Agent-MIP-Request
and
AA-Mobile-Node-Answer
Add MIP-Key-Lifetime to Command Avp Table
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
MIP-Key-Lifetime
| 0 | 0-1 | 0-1 | 0 |
Issue 231: Home-Agent-In-Foreign-Network set by
AAAF
Submitter name: Michael Chen
Submitter email address:
cchen@erilab.com
Date first submitted: 5-Nov-01
Reference:
Document:
mobileip-08-alpha2
Comment type: T
Priority: 1
Section: Mobileip 2.1
Rationale/Explanation of issue:
In session 4.5:
If the mobile
node requests a home agent in the foreign network
either by setting the home
address field to all ones, or by
specifying a home agent in the foreign
network, and the AAAF
authorizes the request, the AAAF MUST set the
Home-Agent-In-Foreign-
Network bit to one.
So the FA MUST include
MIP-Mobile-Node-Address AVP when the
mobile
node requests a home agent
in the foreign network by setting the
home
address field to all ones,
otherwise, AAAF doesn't know mobile node
is willing to be assigned a home
agent in the foreign network
Requested change:
Add this sentence in
session 2.1:
If the mobile node's home address is all ones, the foreign or
home
agent
MUST include a MIP-Mobile-Node-Address AVP which is all ones
in the
AMR.
Issue 232: Session Definition
Submitter
name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first
submitted: 5-Nov-01
Reference:
Document: base
Comment type:
Editorial
Priority: 1
Section: 1.3
Rationale/Explanation of issue:
Past experience with dialup has shown that there are differing
opinions on the definition of a session. For example, some would
consider a session to begin after the user authenticated. Others
would
consider the authentication a part of the session.
PROBLEM: The drafts
are lacking a concise and unambiguous definition
of "session" that we can
all systems-architect and code to. An
airtight definition is important to
ensure predictable and consistent
interoperability among vendors'
implementations of Diameter
applications.
Requested change:
Modify the wording of the definition of Session and add definitions
for Sub-session and Multi-session. These definitions are as follows:
Session
A session is a related progression of events devoted to a
particular activity. Each application SHOULD provide guidelines
as to
when a session begins and ends. All Diameter packets with
the same
Session-Identifier are considered to be part of the
same session.
Sub-session
A sub-session represents a logical break in the activity
of a
single session. These changes in sessions are tracked with the
Accounting-Sub-Session-Id. An example of a session divided into
several
sub-sessions would be a dial-up connection in which the
pre-authentication
activity (call setup, resource allocation,
etc.), interactive login, and PPP
communication would all be
sub-sessions.
Multi-session
A
multi-session represents a logical linking of several parallel
sessions.
Multi-sessions are tracked by using the
Accounting-Multi-Session-Id. An
example of a multi-session
would be a MLP bundle. Each leg of the bundle
would be a
session while the entire bundle would be a multi-session.
Issue 233: MIP-Candidate-Home-Agent-Host
Submitter name: Kevin Purser
Submitter email address:
kevin.purser@ericsson.com
Date first submitted: 06-Nov-01
Reference:
Document: mobileip-08-alpha2
Comment type: T
Priority: 1
Section: 2.1
Explanation of issue:
In the event the AAAF is NOT
willing to allocate a home agent in the visited
network, inclusion of the
required MIP-Candidate-Home-Agent-Host AVP doesn't
make sense.
Requested change:
Make this AVP OPTIONAL in the AMR. Note this is
already correctly reflected
in the AVP table of section 8.1
Issue 234: just a number of editorial nits....
Submitter name: Kevin Purser
Submitter email address:
kevin.purser@ericsson.com
Date first submitted: 09-NOV-01
Reference:
none
Document: base-08-alpha02
Comment type: 'E'ditorial
Priority:
'1'
Section 1.3, Terminology,
-definition of Accounting record
is incomplete (looks like a cut-and-paste
problem); looks like it should be
completed with "diameter nodes" or
something to that effect.
Section 2.6, Connections vs. Sessions,
-figure is mangled
Section 7.1.3, Protocol Errors,
-the definition of
DIAMETER_LOOP_DETECTED says:
An agent detected a loop while trying to get
the message to the Home
Diameter server.
"the Home Diameter server"
should be changed to something like "another
diameter agent" to reflect the
possibility that the request message in
question may not be destined for the
Home Diameter server (consider ASR,
RAR, etc).
Sections 8.4,
8.5, 9.7
-all of the ABNF definitions in these sections list the User-Name
AVP as
mandatory. These should be changed to optional to reflect sessions
which do
not have an associated User-Name (consider NASREQ messages).
Issue 235: Enabling efficient accounting record
uniqueness checking
Issue 235: Enabling efficient accounting record
uniqueness checking
Submitter name: Basavaraj Patil
Submitter email
address: Basavaraj.Patil@nokia.com
Date first submitted: November 9,
2001
Reference:
Document: Base-08
Comment type: T
Priority:
1
Section: 3.0, 9.4
Rationale/Explanation of issue:
If a Diameter
server does not have any indicator in the received
Accounting Requests for
the message being potentially duplicated,
the Diameter server (or a separate
Accounting System) would have
to do a vast amount of unnecessary work just
for the Accounting
Request uniqueness checking.
With more and more "hot
billing" systems and prepaid billing for
packet data becoming prevalent it
becomes a requirement for accounting
messages (records) to be sent far more
frequently and also enabling
speedy evaluation for accuracy and
uniqueness.
For accounting, the section 9.4 (Fault Resilence)
defines
that duplication detection must be based on the
inspection of the
Session-Id and Accounting-Record-Number
AVP pairs. The current draft text
assumes that every
accounting message would be cross-checked with these
identifiers against
the others, to detect duplicate accounting
messages.
However it is far more efficient to o first check if the
Accounting
Request sender has flagged the message to be a potential
duplicate.
(Duplicate messages may be generated in the
exceptional
cases when a communication link between
Diameter peers goes down. This could
happen due to
the sending node failure or the receiving node failure
or
the communication link itself failing. e.g. physically
damaged. When
the sending node is redirecting the traffic
to an alternate peer or able to
communicate again
after a temporary link failure to the primary peer,
it
may send again messages that have not yet
been acknowledged by a recipient
node.)
Duplicates are generated very seldom. (Typically
just a few
packets, for eg. after a link failure case.)
Therefore duplicate checking
all-against-all, by
seems a processing intensive work and one that is
unnecessary to be
performed by accounting servers.
(by the Diameter server
or a billing system).
The 'D' bit would be for all such
accounting
requests that were pending an application layer ack
when the
connection went down, whether they are
resent on a connection to the same
peer or an alternate
peer.
In failover scenarios, duplicate checking
may not necessarily
be done in the Diameter Server. It may
alternatively
be done in a billing engine. In that case the
billing engine
should get the 'D' bit information
from the Diameter header, as delivered
together with
the payload.
(It should be noted that the potentially
duplicated
accounting message may arrive earlier at the end system
than a
non-marked original accounting message. This is
the case with any duplicate
occurrence scenario, but
is not a problem as the end system should anyway
have
some time buffer, e.g. 24h or 12h, for the received
accounting
records to be checked for duplicates.)
The significant benefit achieved
here
is the decrease of uniqueness checking processing
comparisons 1) from
e.g. 77 octets to 1 bit and
2) from cross-comparing all accounting
messages
in the time buffer against each other to comparing
just the very
few potentially duplicated accounting messages to all
other accounting
messages in the uniqueness checking time buffer.
The End-to-End
Identifier could in theory be also
utilized by the uniqueness checkings in
accounting
but has not been defined. Additionally,
the End-to-End
Identifier has recently been considered
to be unique only during a very
limited time period,
e.g. 4 minutes, which would not always be long
enough
when e.g. a sending Diameter client node is in temporary
isolation
due to a network failure for several hours.
The scheme proposed here does
does not limit
the Diameter Server or billing engine to do the
uniqueness
checking in any other way.
(eg. all accounting records checked against each
other,
by the long AVP pair octet strings).
Requested change:
=================
In section 3.0 Diameter
Header
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R
P E r r r r r| Command-Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
would
be:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R
P E D r r r r| Command-Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and
E(rror)
- If set, the message contains a protocol error,
and the message will not
conform to the ABNF
described for this command. Messages with the
'E' bit
set is commonly referred to as an error
message. This bit MUST NOT be set in
request
messages. See section 7.2.
r(eserved) - these flag bits are
reserved for future use, and
MUST be set to zero, otherwise an error MUST
be
sent to the sender.
would get one new flag bit 'D':
E(rror)
- If set, the message contains a protocol error,
and the message will not
conform to the ABNF
described for this command. Messages with the
'E' bit
set is commonly referred to as an error
message. This bit MUST NOT be set in
request
messages. See section 7.2.
(possibly) D(uplicated)
- This bit
is defined only for Accounting Requests,
sent by a Diameter node or
proxy.
If set, the message is possibly a duplicate,
and must be later
checked by a recipient node
if it really is a duplicate. If sending
a
message for first time, this bit MUST be
cleared.
This bit MUST NOT
be set if an answer message
(about e.g. a protocol error) has been got
for
an earlier similar message. It can be used only
in cases where no
answer has been got from the
primary agent for a message and the message
is
sent again (e.g. due to a failover, to an
alternate agent or to a
recovered primary peer
node).
r(eserved) - these flag bits are reserved
for future use, and
MUST be set to zero, otherwise an error MUST be
sent
to the sender.
and in section 9.4 Fault
Resilience
====================================
...
Diameter peers
acting as clients MUST implement the use of failover
to guard against server
failures and certain network failures.
Diameter peers acting as agents or
related off-line processing
systems MUST detect duplicate accounting records
caused by the
sending of same record to several servers and duplication
of messages in transit. This detection MUST be based on the
inspection of
the Session-Id and Accounting-Record-Number AVP pairs.
the above
paragraph would get one sentence to its end:
The inspection MUST be
performed at least for such records
that arrived at the Diameter peer
specifically in accounting
messages which have the 'D' bit set.
Issue 236: DiameterIdentity
Submitter
name: Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first submitted: 08-NOV-01
Reference: none
Document:
base-08-alpha02
Comment type: 'E'ditorial
Priority: '1'
Section: 4.4
(Derived data formats)
Rationale/Explanation of issue:
A couple of
editorial consistency checks dealing with the DiameterIdentity
Requested change:
(1)
The definition:
Diameter-Identity = "aaa://" fqdn [ port ] [ transport ]
[ protocol
] [ security ]
should be changed to:
Diameter-Identity =
"aaa://" fqdn [ port ] [ transport ]
[ protocol ] [ transport-security ]
in order to reference the subsequent grammar rule;
(2)
The
last bit of text:
For example, diameter-host.abc.com would be expanded
to
aaa://diameter-
host.abc.com:TBD;protocol=diameter;transport=sctp.
should be changed to:
For example, diameter-host.abc.com would
be expanded to
aaa://diameter-
host.abc.com:TBD;transport=sctp;protocol=diameter;transport-security=none.
To reflect the proper ordering of the options, as well as the default
for transport-security.
Issue 237: Accounting-Multi-Session-Id AVP in the
HAR
Submitter name: Michael Chen
Submitter email address:
cchen@erilab.com
Date first submitted: 12-Nov-01
Reference:
Document: mobileip-08-alpha2
Comment type: editorial
Priority: 1
Section: Mobileip 1.2 2.3 2.4
Rationale/Explanation of issue:
In
session 1.2 it state,
"The Accounting-Multi-Session-Id AVP in the HAR MUST
be included in
the HAA,
which is then forwarded to the AAAH."
As we
can see in Session 2.3 and 2.4 HAR, HAA ABNF format,
Accounting-Multi-Session-Id AVP is madatory in HAR but option in HAA
Requested change:
Change Accounting-Multi-Session-Id AVP as option
in HAR ABNF Format
The text in Session 1.2 should be changed to something
like
If the Accounting-Multi-Session-Id AVP is in the HAR, Home Agent
must include
this Avp in the HAA, which is then forwarded to the AAAH.
Issue 238: Mip-Feature-Vector AVP in ACR
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 12-Nov-01
Reference:
Document:
mobileip-08-alpha2
Comment type: editorial
Priority: 1
Section:
Mobileip 8.2
Rationale/Explanation of issue:
As we can see,
MIP_Feature_Vector is an option in HAR message so HA
don't know
how to
include this avp in the ACR message in some case.
Requested change:
Add
some text to explain why MIP_Feature_Vector is madatory in ACR or
remove
this
Avp from Accounting Avp Table in session 8.2
Issue 239: Definition of Diameter agent
Submitter name: Yoshihiro Ohba
Submitter email address:
yohba@tari.toshiba.com
Date first submitted: November 12, 2001
Document:
base
Comment type: E
Priority: 1
Section: 1.1, 1.3
Rationale/Explanation of issue:
In section 1.1, it is described that
:
A Diameter agent is a node that does not authenticate and/or
authorize messages locally, such as proxies and relay agents. A
Diameter
server is one that performs authentication and/or
authorization of the user
based on some profile. A Diameter node
MAY act as an agent for certain
requests while act as a server for
others.
According to section 1.1,
a Diameter server IS NOT a Diameter agent.
On the other hand, in section
1.3 it is descibed that :
Diameter Agent
A Diameter Agent is a
host that is providing either server, relay,
proxy, redirect or translation
services.
According to section 1.3, a Diameter server IS a Diameter
agent.
So it seems that there is an inconsistency on whether a Diameter
server is a Diameter agent or not, which should be fixed.
Requested
change:
Excluding Diameter server from the definition of Diamer agent
seems to
be consistent with remaining sections. So I would suggest the
following change in secttion 1.3:
Diameter Agent
A Diameter
Agent is a host that is providing either relay,
proxy, redirect or
translation services.
Issue 240: Time in end-to-end identifier
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 13-Nov-2001
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2001-10/msg00200.html
Document:
base
Comment type: T
Priority: 1
Section: 3.2
Rationale/Explanation of issue:
Initializing the end-to-end
identifier to contain 12 bits of time has
some problems.
1. If the
diameter implementation can generate more than 1,048,575
transactions, it is
possible to get duplicate records. Consider
a NAS that generates 2,097,152
that started generating at time t,
ran for 10 seconds, rebooted, and started
generating again at t +
20. The last record would be t * 0x00100000 +
2,097,152 * 10 = t
* 0x00100000 + 0x1400000. The first record generated is
(t + 20)
* 0x00100000 + 0 = t * 0xFFF00000 + 0x1400000. This is the same
as the last end-to-end before reboot. Note, I ignored the fact
that the
bottom bits are random. This doesn't matter because
in the next second at 2M
transactions per second, that random
number will be seen.
2. The
clock on some embedded systems is reset to zero after reboot.
Thus, the time
would always be the same.
3. NTP can actually make time go backwards
while syncing.
Requested Change:
The 12 bit time initializer is
good for most implementations. But
if another implementation needs to
implement it differently (like
checkpointing the identifier), it shouldn't
have to violate the RFC
to do it. So add a SHOULD to the description.
Upon reboot, the high order 12 bits SHOULD be initiated to contain
the low order 12 bits of current time, while the low order 20 bits
SHOULD be set to a random value.
Issue 241: Accounting issues
Submitter
name: Jaakko Rajaniemi
Submitter email address: jaakko.rajaniemi@nokia.com
Date first submitted: 2001-11-12
Document: base
Comment type: T
Priority: 1
Section: 9.6, 8.2, 9.3
Rationale/Explanation of issue:
It says in the section 9.6 "Correlation of Accounting Records" that the
correlation for accounting sub-sessions is performed using the Session-Id.
Is this correct? Aren't both the Accounting-Sub-Session-Id and Session-Id
used for the correlation?
I think that it is not possible to
terminate one or several accounting
sub-session from the server side. Only
all accounting sub-sessions can be
terminated by using the Abort-Session
command. Is this left for each
application to handle or should this
possibility be in the base protocol?
The accounting state machine in the
section 8.2 describes that the
accounting session is terminated by the
action where the accounting stop
request is sent. It is not totally clear
what the accounting stop request
here can mean. I think that it only
describes the case where the accounted
service is a one-time event (where
EVENT_RECORD is sent and the ACA
terminates the session) and a measurable
length accounting service (where
STOP_RECORD is sent to terminate the
session). However, it seems to be
missing the server initiated termination
by the Abort-Session command.
This application document requirements for
accounting were discussed some
time ago and I proposed a change to the
section 9.3 which got some support,
but not get to the base-08. The issue is
that because it is possible that a
service makes only use of the Accounting
portion of the Diameter application
then the application must clearly
described in the application specification
which part contains the
accounting portion. The current text describes in
the section 9.3
(Application document requirements) clearly how new
accounting AVPs must be
described in new applications but it does not say
anything how new
accounting command codes should be described. One way to
guarantee that this
is clearly described in the new applications is to
modify the section 9.3
according to the changes proposed in the Requested
change part below.
Requested change:
The change to the section 9.3, the Application
document requirements:
"Each Diameter application (e.g. NASREQ,
MobileIP), MUST define their
Service-Specific accounting part in a section
entitled "Accounting". Under
the section "Accounting" they MUST define their
Service-Specific AVPs that
MUST be present in the Accounting-Request message
in a section entitled
"Accounting AVPs" and their Service-Specific command
codes if exists in a
section entitled "Accounting Command-Codes". The
application MUST assume
that the AVPs described in this document will be
present in all Accounting
messages, so only their respective
service-specific AVPs need to be defined
in this section."
If the
above change is adopted then it would require some minor editing to
the
NASREQ and Mobile IP application.
For other question changes are still
open.
Issue 242: Specifying Vendor in Command ABNF
Submitter name: Mark Eklund
Submitter email address: meklund@cisco.com
Date first submitted: 13-Nov-2001
Reference:
Document: base
Comment type: E
Priority: 1
Section: 3.2
Rationale/Explanation
of issue:
There is no way to specify the vendor id in the ABNF. Thus a
vendor
specific command code cannot be specified.
Requested change:
Change the ABNF in section 3.2 to allow vendor. I give one suggestion
below, but am open to alternatives.
Change
header = "<
Diameter-Header:" command-id [r-bit]
[p-bit] [e-bit] ">"
to
header = "< Diameter-Header:" [vendor-id]command-id [r-bit]
[p-bit] [e-bit] ">"
vendor-id = 1*DIGIT ":"
; the
Vendor-ID field value
Issue 243: Session State Machine for Diameter
agents
Submitter name: Yoshihiro Ohba
Submitter email address:
yohba@tari.toshiba.com
Date first submitted: November 13, 2001
Document:
base
Comment type: E
Priority: 1
Section: 8.1, 8.2
Rationale/Explanation of issue:
Authorization Session State Machine
and Accounting Session State
Machine seem to define FSM for Diameter clients
and servers but not
for Diameter agents (i.e., relay, proxy, redirect and
translation
agents).
For example, in section 8.1, when a
Service-specific authorization
request is received from a peer in Idle
state, there is no action to
*forward* the received request to the next-hop
peer of the session and
move to Pending state, which would be a normal
action for relay
agents. Similarly, when a Service-specific authorization
answer is
received from the next-hop peer of the session in Pending state,
there
is no action to *return* the received answer to the previous-hop peer
of the session and move to Open state (in the case of stateful relay
agents) or Idle state (in the case of stateless relay agents), which
would also be a normal action for relay agents.
Requested change:
Additional state transitions need to be included in section 8.1 and
8.2 to support relay, proxy, redirect and translation agents.
Issue 244: ELECTION_LOST result code
Submitter name: Michael Chen
Submitter email address: cchen@erilab.com
Date first submitted: 19-Nov-01
Reference:
Document: base-08
Comment type: E
Priority: 1
Section: Base: 5.4.3
Rationale/Explanation of issue:
DPR is not sent to its peer when
lost the election so ELECTION_LOST
result code is not used.
Requested change:
Remove this result code.
Issue 245: User-Name avp in the RAR and RAA
message
Submitter name: Michael Chen
Submitter email address:
cchen@erilab.com
Date first submitted: 19-Nov-01
Reference:
Document: base-08
Comment type: E
Priority: 1
Section: Base:
8.3.1 8.3.2 10.1
Rationale/Explanation of issue:
User-Name avp
should be option is the RAR and RAA message
There is typepo in the RAA which
shows "RAR" in the ABNF
Requested change:
1. change User-Name Avp as
option in the ABNF of RAR and RAA
2. change the RAR typepo to RAA
3.
change the comand avp table according to this issue
Issue 246: Accounting-*-Extended-Octets numbers
are inconsistent
Submitter name: Mark Eklund
Submitter email
address: meklund@cisco.com
Date first submitted: 21-Nov-01
Reference:
Version 8
Document: nasreq
Comment type: E
Priority: 1
Section:
2.2, 8.*
Rationale/Explanation of issue:
The AVP numbers are
inconsistent.
Section 2.2 8.0
Accounting-Input-Extended-Octets
42/Unsigned64 363/Unsigned64
Accounting-Input-Extended-Packets 57/Unsigned64
365/Unsigned64
Accounting-Output-Extended-Octets 43/Unsigned64
364/Unsigned64
Accounting-Output-Extended-Packets 48/Unsigned64
366/Unsigned64
Also, AVPs with values greater than 255 shouldn't be
listed in section
2.2, "Legacy RADIUS Attributes".
Requested change:
Fix the numbers in section 2.2.
Move AVPs with values greater
than 255 to section 2.1.
Issue 247: Inconsistencies between the base and
transport drafts
Submitter name: Jonathan Wood
Submitter email
address: jonathan.wood@sun.com
Date first submitted: 21-Nov-01
Reference:
Document: base
Comment type: E
Priority: 1
Section: Base (version 8 alpha2), sections 5.6, 5.6.2, and 12
Rationale/Explanation of issue:
The transport draft and the base
spec are in conflict about
sending watchdogs. The state machine in the base
spec section 5.6
requires that watchdogs be sent on each expiration of the
watchdog
timer. However, the transport draft requires that a watchdog be
send once on the first expiration of the watchdog timer. On the
next
expiration of the watchdog timer, the connection is put in
the suspect
state, and the connection is failed over.
Also, section 5.6 states
When the state machine below requests a
transport connection with
the peer, the state machine in [52] is
invoked. Once the connection has been
established, the state machine
in this section is followed.
This is
not completely accurate. The state machine in the transport
draft should be
followed throughout the life of the connection as
well to manage the
connection.
There are also some leftover timer descriptions in section
12 that
are no longer relevant.
Requested change:
I
recommend that text specifying how to control sending watchdogs and
management of the watchdog timer be stricken from the base spec, and
that the base spec refer to the transport draft on this matter.
Specifically:
5.6 Peer State Machine
(Modify 2nd paragraph)
This state machine is closely coupled with the state machine
described in [52], which is used to open, close, failover, probe,
and
reopen transport connections. Note in particular that [52]
requires the use
of watchdog messages to probe connections. For
Diameter, DWR and DWA
messages are to be used.
Remove from R-Open:
WatchDog-Timer
R-Snd-DWR R-Open
Remove from I-Open:
WatchDog-Timer I-Snd-DWR
I-Open
Remove from section 5.6.2 Events:
WatchDog-Timer The
Watchdog timer expired, indicating that a DWR
message is to be sent to the
peer.
Rcv-DWR A DWR message was received.
Rcv-DWA A DWA message
was received.
Section 12.0 Diameter protocol related configurable
parameters
Recommend removing the following timers:
Td timer
The Td timer controls the termination of connections with peer
in the
SUSPECT state. The recommended value is 5 seconds.
Ti timer
The Ti
timer controls the frequency the watchdog messages are
to be sent to idle
peers. The recommended value is 30 seconds.
Tr timer
The Tr timer
controls the frequency the watchdog messages are
to be sent to peers when
there are pending requests, but not
messages have been received from the
peer. The recommended
value is 10 seconds.
Tw timer
The Tw timer
controls the changing of a peer to the SUSPECT
state when no answer is
received to a watchdog request. The
recommended value is 5 seconds.
What about the Tc timer?
Issue 248: Error messages: decimal or hex?
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email
address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type:
Priority: 2
Section: 7.1
Rationale/Explanation of issue:
Diameter distinguishes error classes
according to the DECIMAL value of
the Result-Code data field. This is widely
used in protocols that
utilize ASCII encoding (SMTP, HTTP, etc.). But it
doesn't make much
sense in a binary protocol such as Diameter. Shouldn't the
HEX value
of the Result-Code data field be used instead?
For
example:
Is an Informational error message 1000 - 1999 in DECIMAL? Or is
it
10000000 - 1FFFFFFF in HEX?
Proposed resolution to #248
From: Mark Eklund
Date: Fri Jan 25
00:32:49 2002
I was considering Issue 248 which questions if the
Result-Code AVP
values should be in decimal or hexadecimal. After considering
the
pros and cons, I think we should leave it as decimal. I see two
main
reasons to change this to Hexadecimal.
1. This allows for a
bitmask to determine what type of error was sent.
2. In doing this we
will also expand the range of codes for each
result and thus we can have over
a 1000 protocol errors.
My thoughts are
1. Categorizing these errors
in groups of 1000 is mostly a
documentation convenience. In essence to an
application, the
Result-Code AVP is either Success, a few failures that
it
handles specially and all the other failures. There is little need
to
distinguish Transient Failures and Permanent Failures.
Protocol Errors will
be in a packet with the 'E' bit set.
So being able to use a bitmask to
determin what type of error was
sent is of little.
2. We have used
less than 50 total Result-Codes. Yes, it is possible
that we will have used
up an entire 1000 as some time. If that
happens, we can simply add another
range of 1000 for that type of
error. Once again, these categorizations are
simply a
documentation convenience.
3. This is a personal preference,
but when I see a dump of a diameter
packet, I typically see the packet broken
into information where
Unsigned32 values converted to decimal. This is a lame
argument,
but I had to have one more than the arguments for hexadecimal
:)
With all that said. If there is a want or push for Hexadecimal,
now
is the time to fix it. Remember though that if this changes,
everyone
that working diameter servers will have to go update their enums
and
dictionaries :(
-Mark
Issue 249: Editorial nits in Diameter Base -08
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email
address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Editorial
Priority: 1
Section:
Rationale/Explanation of issue:
Page 7, section 1.1, 3rd paragraph, last
sentence:
Change
"AVPs are used by base Diameter" to "AVPs are used by
the base Diameter"
Page 12, section 3.0-, 3rd paragraph:
"Diameter Servers must support the base protocol"
Shouldn't the
must be capitalized?
Page 14, section 2.1, third and fourth paragraphs:
Change: "ICMP protocol and port unreachable messages" to "ICMP protocol
port unreachable messages".
"If Diameter receives data to from TCP
that" to "If Diameter receives data
from TCP that"
Page 16, Section
2.3.4, first paragraph:
Change "Applications Identifiers is different from
the ones" to
"Applications Identifiers are different from the ones"
Page 111, Section 11.1.1, second paragraph
Change:
"is set to a
non-zero value, is for Private Use" to
"is set to a non-zero value, are for
Private Use"
Same change in section 11.2.1 on page 111 also.
Issue 250: Normative versus Informative
references
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted:
29-Dec-01
Reference:
Document: all
Comment type: Editorial
Priority: S
Section: References
Rationale/Explanation of issue:
RFC Editor has indicated that future RFCs will need to separate Normative
versus Informative references.
Issue 251: References to ADIF in NASREQ-08
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email
address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: NASREQ 08
Comment type: Editorial
Priority: 1
Section:
7.3.4 and 7.4.4
Rationale/Explanation of issue:
Support for ADIF was
removed a while back
In both sections it is stated "This AVP SHOULD Be
included in the ADIF
Record of the corresponding Accounting-Request
messages"
Suggestion: strike "the ADIF Record of"
Issue 252: Granting Access via Accounting
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email
address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Technical
Priority: S
Section:
8.2
Rationale/Explanation of issue:
Access is not granted based on
receipt of a successful
accounting start answer
Change:
In the
state table on pp. 86, it states that in Pending state, receipt of
a
Successful accounting start answer results in "grant access" and
movement to
the Open state. Since access is granted within the
authentication/authorization state machine, this appears to be an error.
Issue 253: Diameter Peer Discovery
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email
address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Technical
Priority: 1
Section:
5.2
Rationale/Explanation of issue:
A6 RRs are now deprecated, and the
text doesn't mention how to
discover TLS support on the peer.
Change:
3. The Diameter implementation uses DNS to request the
SRV RR [33] for the
'_diameter._sctp' and/or '_diameter._tcp' server in a
particular realm"
To:
3. The Diameter implementation uses DNS to
request the SRV RR [33] for the
'_diameter-tls._sctp' and/or
'_diameter-tls._tcp' in a particular realm,
as well as the '_diameter._sctp'
and/or '_diameter._tcp' servers.
If records corresponding to the TLS ports
are found, the Diameter peer is
assumed to support TLS.
Change:
"Address records include A RR's, AAAA RR's, A6 RR's or other similar"
To:
"Address records include A RRs, AAAA RRs or other similar"
Issue 254: More details needed on Diameter IPsec
usage
Submitter name: Bernard Aboba aboba@internaut.com
Submitter
email address: aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Technical
Priority: S
Section: 2.2
Rationale/Explanation of issue:
The IPsec mode is not
specified. IPsec is also mispelled (do a global
replace of IPSec with
IPsec).
Add:
"All Diameter implementations MUST support IPsec
ESP [RFC2406] in transport
mode with a non-null transform to provide
per-packet authentication,
integrity protection and confidentiality, and
MUST
support the replay protection mechanisms of IPsec.
Diameter
implemenations MUST support IKE
for peer authentication, negotiation of
security associations, and
key management, using the IPsec DOI [RFC2407].
Manual keying MUST NOT
be used since it does not provide the necessary
rekeying support.
Diameter implementations MUST support peer
authentication using a pre-shared key, and MAY support certificate-based
peer authentication using digital signatures. Peer authentication using
the public key encryption methods outlined in IKE's sections 5.2 and 5.3
[RFC2409] SHOULD NOT be used.
Conformant implementations MUST
support both
IKE Main Mode and Aggressive Mode. When pre-shared keys are
used for
authentication, IKE Aggressive Mode SHOULD be used, and IKE Main
Mode
SHOULD NOT be used. When digital signatures are used for
authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used.
In all cases, access to locally stored secret information (pre-shared
key, or private key for digital signing) must be suitably restricted,
since compromise of the secret information nullifies the security
properties of the IKE/IPsec protocols.
When digital signatures are
used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate
Request Payload(s) to specify the
certificate authority (or authorities)
that are trusted in accordance
with its local policy. IKE negotiators SHOULD
check the pertinent
Certificate Revocation List (CRL) before accepting a PKI
certificate for
use in IKE's authentication procedures.
The Phase 2
Quick Mode exchanges used to negotiate protection for
Diameter connections
MUST explicitly carry
the Identity Payload fields (IDci and IDcr). The DOI
provides for
several types of identification data. However, when used in
conformant
implementations, each ID Payload MUST carry a
single IP
address and a single non-zero port number, and MUST NOT use
the IP Subnet or
IP Address Range formats. This allows the Phase 2
security association to
correspond to specific TCP and SCTP
connections.
Since IPsec
acceleration hardware may only be able to handle a limited
number of active
IKE Phase 2 SAs, Phase 2 delete messages may be sent
for idle SAs, as a
means of keeping the number of active Phase 2 SAs to
a minimum. The receipt
of an IKE Phase 2 delete message SHOULD NOT be
interpreted as a reason for
tearing down a Diameter connection.
Rather, it is preferable to leave the
connection up, and if additional
traffic is sent on it, to bring up another
IKE Phase 2 SA to protect it.
This avoids the potential for continually
bringing connections up and
down.
If an IKE implementation receives
a Phase 1 Delete message for a Phase 1
Security Association bound to one or
more sessions, then it SHOULD
delete the associated IKE Phase 2 security
associations."
Issue 255: Translation of RADIUS vendor-specific
attributes
Submitter name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date first submitted:
28-Dec-01
Reference:
Document: nasreq 08
Comment type: Technical
Priority: S
Section: 9.1
Rationale/Explanation of issue:
There
is no discussion of how RADIUS vendor-specific attributes are to be
translated to Diameter AVPs and vice-versa.
Issue 256: TLS Usage Issues
Submitter
name: Bernard Aboba aboba@internaut.com
Submitter email address:
aboba@internaut.com
Date first submitted: 28-Dec-01
Reference:
Document: base 08
Comment type: Technical
Priority: S
Section:
2.2
Rationale/Explanation of issue:
There is no discussion of how TLS
authentication is used with
Diameter. For example:
a. Are both peers
required to support certificates?
b. If not, how is it decided which peer
authenticates to who?
Proposed change:
Add:
"Diameter
clients act as TLS clients according to [RFC2246], and Diameter
servers act
as TLS servers. Diameter clients and servers implementing
TLS for security
MUST mutually authenticate as part of TLS session
establishment. In order to
ensure mutual authentication, Diameter servers
MUST request certificates
from Diameter clients, and the client MUST be
prepared to supply a
certificate on request."
Issue 257: peer connection inconsistent between
base08 and transport05
Submitter name: yanqun le
Submitter email
address: yanqun.le@nokia.com
Date first submitted: 30-Dec-01
Reference:
Document: Base -08, dratf-ietf-aaa-transport-05
Comment type: Technical
Priority: S
Section: Section 5.1 of Base- 08, Section 3.4.1 of Transport
-05
Rationale/Explanation of issue:
The last third paragraphs in Section
5.1 is inconsistent with Section 3.
4.1 of transport-05.
Requested
change:
The last third paragraphs in Section 5.1 should be changed to:
When a peer is deemed suspect, which could occur for various
reasons, including not receiving a DWA within an alloted timeframe, no
new requests should be forwarded to the peer, and failover procedures
should be invoked. When an active peer is moved to this mode, additional
connections SHOULD be established to ensure that the necessary number of
active connections exists.
There are two ways that a peer is removed
from the suspect peer list:
1. the peer's watchdog timer has expired without
a response,
causing a trasport reset or close to be done on the connection.
2. a response is received from the peer within the watchdog timer,
and
the connection to the peer is considered stabilized.
In the event the
peer being removed is either the primary or
secondary, an alternate peer
SHOULD replace the deleted peer, and assume
the role of either primary or
secondary.
Issue 258: CER first or watchdog first when
reopening a connection
Submitter name: yanqun le
Submitter email
address: yanqun.le@nokia.com
Date first submitted: 30-Dec-01
Reference:
Document: dratf-ietf-aaa-transport-05
Comment type: Technical
Priority: S
Section: 3.4.1
Rationale/Explanation of issue:
In
section3.4.1 [5] of draft-ietf-aaa-trasport-05, it said:
If the connection
is successfully opened, then the watchdog message is
sent. Once three
watchdog messages have been sent and responded to, the
connection is
returned to service, and transactions are once again sent
over it.
I
wonder:
When a connection to a peer comes up from DOWN status, i.e. reopen a
connction, does it need exchange capabilities again?
If capabilities
exchange is needed does it send Watchdog first or
exchange CER/CEA first?
Resolution: If a connection is CLOSED, and then re-opened, capabilities exchange is indeed needed, so CER/CEA is handled first.
Issue 259: Qualifier of
Vendor-Specific-Application-Id in CEA
Submitter name: Miguel-Angel
Pallares
Submitter email address:
miguel-angel.pallares-lopez@ece.ericsson.se
Date first submitted: 02-Jan-02
Reference:
Document: Base 08
Comment type: Editorial
Priority: 1
Section: 5.3.2
Rationale/Explanation of issue:
The qualifier for
Vendor-Specific-Application-Id AVP in CEA should be "*", as in CER.
Change in definition of CEA in 5.3.2, from:
[
Vendor-Specific-Application-Id ]
to:
* [
Vendor-Specific-Application-Id ]
Issue 260: SNTP referencing
Submitter
name: Jari Arkko
Submitter email address: jari@arkko.com
Date first
submitted: 02-Jan-02
Reference:
Document: Base 08
Comment type:
Technical
Priority: S
Section:
Rationale/Explanation of issue:
Current text reads as follows:
The Time format is derived from the
Unsigned32 AVP Base Format.
This is 32 bit unsigned value containing the
four most
significant octets returned from NTP [18], in network byte
order.
This represent the number of seconds since 0h on 1
January 1900
with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will
overflow. NTP
[18] describes a procedure to extend the time to
2104.
This has two
problems. First, it is unclear whether NTP or SNTP
is meant and what format
is really used. Second, we don't
mandate the extension to year 2104.
Also, I find it easier to explain the format issue if Time
is
derived from OctetString, not Unsigned32. Bits on the wire
are not changed.
Proposed change:
The Time format is derived from the OctetString
AVP Base
Format. The string MUST contain four octets, in the same
format
as the four first bytes are in the NTP Timestamp
Format. The NTP Timestamp
format is defined in Chapter 3 of
reference [18].
This represents
the number of seconds since 0h on 1 January 1900
with respect to the
Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the
time value will
overflow. SNTP [18] describes a procedure to extend the time
to
2104. This procedure MUST be used by all DIAMETER nodes.
Issue 261: Peer discovery mechanism
requirements
Submitter name: Jari Arkko
Submitter email address:
jari@arkko.com
Date first submitted: 02-Jan-02
Reference:
Document:
Base 08
Comment type: Technical
Priority: S
Section: 5.2
Rationale/Explanation of issue:
Current text does not clearly enough
specify
which peer discovery mechanisms are mandatory
and which are not.
There's two approaches to handling this issue.
One, (apparently the
current approach) we stay
clear of using MUST/SHOULD/MAY in section 5.2
and therefore all of the text falls to Informative,
and nothing is
really mandated.
The second approach is that we explicitly state
what DIAMETER nodes MUST/SHOULD/MAY be capable of
in this area. I favor
the latter approach.
Proposed change:
Indicate in the list under
5.2 that the first
option (manual configuration) MUST be supported
by
all DIAMETER nodes, while the latter two options
(SRVLOC and DNS SRV
records) MAY be supported.
Issue 262: A Diameter node must use its own TLS
certificate Issue 263: Mandate required TLS cipher suites
Issue 264: User-Name in Answer messages
Issue 265: MIP-Reg-Reply AVP not required in AMA
for Co-located MN Issue 266: Returning AAAF-Generated FA-HA Key to
FA Issue 267: Minor corrections/clarifications to
draft-mobileip-08 Issue 268: Diameter Extensibility
Issue 269: Diameter -07 introduction needs
improvement Issue 270: Sections 5.6.2 - Rcv-Message - add
DPR,DPA Issue 272: Separation of the prepaid and postpaid
accounting sessions Issue 273: DNS SRV text needs to be
updated From: David Frascone Issue 274: Add AAA to terminology Issue 275: Changes to state machine for ASR/ASA
messages Issue 276 : Remove section 1.6 from the CMS
appl Resolution: The section 1.6 that was in -03 is removed from -04. (The
-03 Issue 277: session-id & user-name AVPs; NASREQ
inconsistancies Issue 278: CMS issues Comments from Stephen Farrell:
This one contains a bunch of different things: Issue 279: Base does not sufficiently explain what
MAY encrypt means Issue 280: close of 277 Issue 281: transport state
references Issue 282: allow redirect agents to have the
option of providing user to server address resolution. Issue 283: Usage of TLS vs. IPsec Issue 284: Possible modification to the Diameter
Cost Control Application protocol Issue 285: Another accounting AVP
issue... Issue 286: MIP-Home-Agent-Host AVP Issue 287: Overloaded URI Issue 288: Setting the M bit. Issue 289: Routing of session messages defined in
base Issue 290: Handling of Accounting-Multi-Session-Id
AVP Issue 291: Remove references to CMS-Cert in
cms-sec-03 Resolution: The string CMS-Cert doesn't occur in -04. Issue 292: Handling of
Home-Agent-In-Foreign-Network flag Issue 293: Relax Service-Type from REQUIRED to
RECOMMENDED in nasreq Issue 294: NASREQ Key Distribution
Insecure [BA Comment]:
A concrete example of an attack that takes advantage of lack Issue 295: More NASREQ AVPs
needed Issue 296: Possible new AVP for
MobileIPv4 Issue 297: NASREQ-specific values for
Termination-Cause AVP Issue 298: Minor corrections to
mobileip-09 Issue 299: Need more explanation about handling MN
handoffs Issue 300: EAP corner conditions "2.6. Usage guidelines
Submitter name: Don Zick
Submitter email address:
Date first submitted: 08-Jan-02
Reference:
Document: Base 08
Comment type: Technical
Priority: 1
Section: 2.2
Rationale/Explanation of issue:
The Diameter base draft does not address
how to ensure that a Diameter
node is using its own TLS certificate. It is
important to ensure that
a Diameter node is using its own TLS certificate so
that if a single
Diameter node becomes compromised, it won't break security
for all of
the other Diameter nodes.
It is a common practice with
TLS to put a node's identity into the
certificate's subjectAltName dNSName
field. The Diameter CMS Security
Application takes this approach. Below is a
section from the Diameter
CMS Security Application draft 3:
>3.2
Certificate Requirements
>
> Certificates used for the purposes of
Diameter MUST conform to the
> PKIX profile [4], and MUST also include a
Diameter node's FQDN, which
> is typically added in the Origin-Host AVP
[1], as one of the values
> of the subjectAltName extension of the
Certificate. The FQDN is to
> be encoded as a dNSName within the
subjectAltName. >
> For Diameter nodes (capable of acting as
recipients for
> confidentiality), the FQDN MUST be of the form
>
"Diameter-
>
scheme. Note that this naming constraint is for PKI purposes only,
> and
in no way restricts a Diameter's host name.
Requested change:
Make Diameter TLS have the same dNSName field requirements as the
Diameter CMS Security Application.
Submitter name: Don Zick
Submitter email address:
Date first
submitted: 08-Jan-02
Reference:
Document: Base 08
Comment type:
Technical
Priority: S
Section: 2.2
Rationale/Explanation of issue:
Diameter implementations should not be required to support all TLS
cipher suites listed in RFC 2246. Not all cipher suites are supported
by
available TLS tool kits and one cipher suite contains the proprietary
IDEA
encryption algorithm that you have to get permission to use.
Therefore, to
ensure inter operability, it is necessary to specify which
cipher suites
must be supported.
Requested change:
Add:
Diameter nodes
MUST be able to negotiate the following TLS cipher
suites:
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Diameter nodes MAY negotiate other TLS
cipher suites.
Submitter name: Bob Kopacz
Submitter email address:
BKopacz@InterlinkNetworks.com
Date first submitted: 10-Jan-02
Reference:
Document: mobile-ip, nasreq 08
Comment type: Technical
Priority: 1
Section: Occurrence rules tables, and Message ABNFs
Rationale/Explanation of issue:
The rules for the inclusion of the
User-Name AVP in Answer
messages are inconsistent. In draft-08:
The
User-Name AVP MUST be echoed back (1 occurrence required)
in these Answer
messages:
Re-Auth-Answer (base protocol)
Abort-Session-Answer (base
protocol)
Session-Terminate-Answer (base protocol)
Accounting-Answer
(base protocol)
The User-Name AVP MAY be echoed back (0-1 occurrence)
in these Answer messages:
AA-Answer (nasreq)
Diameter-EAP-Answer
(nasreq)
The User-Name AVP MUST NOT be echoed back (0 occurrences
required)
in these Answer messages (which caused conflicts at the recent
bakeoff):
AA-Mobile-Node-Answer (mobile ip)
Home-Agent-MIP-Answer (mobile ip)
Requested change:
Since it
is natural and harmless for an implementation to echo back
the User-Name,
allow but do not require the User-Name AVP to appear in
Answer messages, if
present in the Request.
Submitter name: Bob Kopacz
Submitter email
address: BKopacz@InterlinkNetworks.com
Date first submitted: 10-Jan-02
Reference:
Document: mobile-ip 08
Comment type: Technical
Priority: 1
Section: 2.2
Rationale/Explanation of issue:
Sesion 2.2 of the Mobile-IP draft-08 states that "An AMA message with
the Result-Code AVP set to DIAMETER_SUCCESS MUST include the [...]
MIP-Reg-Reply AVP."
In the case of a co-located MN, however, the
AAAH would be sending the
AMA as a direct response to the AMR, with no
HAR/HAA messages
involved, so in this case the AMA would not contain a
MIP-Reg-Reply
AVP.
This was first noted by Siva Ramamurthy on the
AAA-WG mailing list
on 11-28-2001.
The occurrence rule table and
message ABNF are ok.
Requested change:
Change the first
sentence of the second paragraph
From:
An AMA message with the
Result-Code AVP set to DIAMETER_SUCCESS MUST
include the
MIP-Home-Agent-Address, MIP-Home-Mobile-Node-Address and
MIP-Reg-Reply AVPs.
To:
An AMA message with the Result-Code AVP set to
DIAMETER_SUCCESS MUST
include the MIP-Home-Agent-Address AVP, MUST include
the
MIP-Home-Mobile-Node-Address AVP, and includes the MIP-Reg-Reply AVP
if and only if the Co-Located-Mobile-Node bit was not set in the
MIP-Feature-Vector AVP.
Submitter name: Bob Kopacz
Submitter email address:
BKopacz@InterlinkNetworks.com
Date first submitted: 15-Jan-02
Reference:
Document: mobile-ip 08
Comment type: Technical
Priority: 1
Section: 2.2, 2.4, 5.4, 8.1, Issue#203
Rationale/Explanation of issue:
[The following is based on some issue#203-related emails
exchanged
with Mark Eklund. The proposal I'm contributing here
is also Mark's, as I
understand it]
When the HA is in the foreign network and a FA-HA key
is
requested, the AAAF, rather than the AAAH, generates the key.
Here's the diagram of the issue:
amr-> amr->
FA
--------> AAAF1 -------------> AAAH
<-ama <-ama |
| ^
|
|
har | haa
| |
V |
|
<-har <-har |
HA
<-------- AAAF2 <---------------/
haa-> haa->
In the
above diagram, FA & HA & AAAF1 & AAAF2 are all in the same
visited network. AAAF1 and AAAF2 may be the same server, or may
be
different servers.
In the above diagram, AAAF2 generates the FA-HA key.
The problem is that this key must somehow be returned to the FA
via
AAAF1. The proposal here is to pass the key back to the FA
via the the HAA
and AMA messages. AAAF2 may be concerned about
security, so may want the
FA-HA key to be passed encrypted so
that AAAH and intervening servers can't
figure it out, but AAAF1
can somehow decrypt it.
The details are:
1. A new HAA-to-AMA-Data AVP, of type octetstring, is created.
The
purpose of this AVP is convey information from the HA's AAAF
(AAAF2) to the
FA's AAAF (AAAF1). All AAAFs in that foreign
realm MUST have an agreed upon
format and security method for
this AVP to be used. (It may be possible to
use CMS security
to somehow encrypt this AVP, but it is unclear just how, as
it
involves the AAAH copying a secure AVP from the HAA to the AMA,
and
the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured
AVPs)
2. When
the FA-HA key is generated by AAAF2, this key must
somehow be conveyed to
AAAF1. There are two ways to do this:
a. Use the MIP-HAA-to-AMA-Data AVP, or
b Have a common database among AAAFs in the foreign network,
wherein
AAAF2 may deposit the FA-HA key, which is later retrieved
by AAAF1, in a
proprietary manner not described in the Diameter
documents.
3. If
the HAA-to-AMA-Data AVP is present in the HAA, the AAAH
treats it as opaque
data and passes it in the AMA.
4, If AAAF1 receives the HAA-to-AMA-Data
AVP in the AMA, AAAF1
will use this AVP to recreate the FA-HA key, and
replace this AVP
by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA.
Requested change:
This issues supercedes issue#203, which
also addresses the
problem of returning an AAAF-Generated FA-HA Key to the
FA, but
didn't quite work in the case where there was a 2nd AAAF
involved.
In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF.
In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF.
In
section 6, define the following new AVP:
6.x HAA-to-AMA-Data AVP
The HAA-to-AMA-Data AVP (AVP Code TBD) is of type OctetString and
may be used, when the HA is allocated in the foreign network and
the
HA's AAAF generates the FA-HA key, to convey the FA-HA key
information (in
some proprietary format and security method which
is agreed-upon by all AAAF
servers in the foreign network) back
to the FA's AAAF.
In section
8.1. Add a row for the new HAA-to-AMA-Data AVP, with these
occurrence rules:
AMR 0, AMA 0-1, HAR 0, HAA 0-1.
Replace section 5.4 by
If the
home agent is in the home realm, then AAAH has to generate
the Foreign-Home
session key. Otherwise, it is generated by the
AAAF receiving the HAR.
If the AAAH generates the Foreign-Home session key, then the AAAH
includes the session key in the MIP-HA-to-FA-Key AVP, and
includes the
AVP as part of the HAR message sent to the home
agent. The corresponding
session key that is to be sent to the
foreign agent is cached on the AAAH
until the HAA is received, at
which time the AAAH adds the MIP-FA-to-HA Key
AVP to the AMA,
using the SPI in the MIP-FA-to-HA-SPI.
Upon receipt
of the HAR, the home agent recovers the Foreign-Home
session key, allocates
an SPI to be used with the key. The
allocated SPI is included in the HAA's
MIP-FA-to-HA SPI AVP.
If the AAAH doesn't generate the Foreign-Home
session key, then
upon receipt of the HAA, the AAAH extracts and passes the
MIP-FA-to-HA-SPI AVP (if present in the HAR) in the AMA, and
extracts
and passes the HAA-to-AMA-Data AVP (if present in the
HAR) in the AMA.
If the AAAF receives an AMA which contains a HAA-to-AMA-Data AVP,
the AAAF will recreate the FA-HA key, generate a MIP-FA-to-HA-Key
AVP,
and pass the MIP-FA-to-HA-Key AVP to the FA.
Alternatively, if the AAAF
generates the Foreign-Home session
key, the AAAFs in the foreign network may
have a common database
among AAAFs, wherein the HA's AAAF may deposit the
FA-HA key,
which is later retrieved by the FA's AAAF, in a proprietary
manner not described in the Diameter documents.
Submitter name: Bob Kopacz
Submitter email
address: BKopacz@InterlinkNetworks.com
Date first submitted: 17-Jan-02
Reference:
Document: mobile-ip 08
Comment type: Technical
Priority: 1
Section: 4.6.1, 6.8
Rationale/Explanation of issue:
Minor corrections/clarifications.
Requested change:
In
section 4.6.1, 2nd line of 1st paragraph, change "algorithm"
to "algorithm
and secret" What follows is the existing 4.6.1
> 4.6.1 MIP-MN-AAA-SPI
AVP
>
> The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type
Unsigned32 and
> indicates the algorithm by which the targeted AAA server
(AAAH)
> should attempt to validate the Authenticator computed by the
mobile
> node over the Registration Request data.
In section 6.8,
change the name of the 3rd enumerated value
from "SHA-1" to "HMAC-SHA-1".
What follows is the current 4.6.1:
> 6.8 MIP-Algorithm-Type
AVP
>
> The MIP-Algorithm-Type AVP (AVP Code 345) is of type
Enumerated, and
> contains the Algorithm identifier used to generate the
associated
> Mobile IP authentication extension. The following values are
> currently defined:
>
> 1 Prefix+Suffix MD5 [4]
> 2
HMAC-MD5 [13]
> 3 SHA-1 [17]
[The following, taken from "AAA
Registration Keys for Mobile IP",
(draft-ietf-mobileip-aaa-key-09.txt),
refers to "HMAC-SHA-1"]
> 3. Dynamic Security Associations
>
> Mobility Security Associations between Mobile IP entities
>
(mobile nodes, home agents, foreign agents) contain both the
> necessary
cryptographic key information, and a way to identify
> the cryptographic
algorithm which uses the key to produce the
> authentication information
typically included in the Mobile Home
> Authentication extension or the
Mobile Foreign Authentication
> extension. In order for the mobile node
to make use of key material
> created by the AAA server, the mobile node
also has to be able to
> select the appropriate cryptographic algorithm
that uses the key
> to produce the authentication. The following table
contains the
> supported algorithm identifiers.
>
>
Algorithm Identifier Name Reference
> ---------------------
------------------ ------------
> 1 MD5/prefix+suffix RFC 2002 [11]
> 2 HMAC-MD5 RFC 2104 [6]
> 3 HMAC-SHA-1 RFC 2104 [6]
Submitter name: Randy Bush
Submitter email address: randy@psg.com
Date first submitted: 29-Dec-01
Reference:
Document: Base 08
Comment type: Technical
Priority: S
Section:
Rationale/Explanation of issue:
is eeems that the results of the
discussion last may of vendor-specific
commands never made it into the
documents. in specific.
---
25 of the base:
"The
Command-Code field is three octets, and is used in order to
communicate the
command associated with the message. The 24-bit address
space is managed by
IANA (see section 11.2).
In the event that the Command-Code field
contains a vendor specific
command, the four octet Vendor-ID field contains
the IANA assigned "SMI
Network Management Private Enterprise Codes" [2]
value. If the
Command-Code field contains an IETF standard Command, the
Vendor-ID field
MUST be set to zero (0). Any vendor wishing to implement a
vendor-specific
Diameter command MUST use their own Vendor-ID along with
their privately
managed Command-Code address space, guaranteeing that they
will not
collide with any other vnedor's vendor-specific command, nor with
future
IETF applications."
---
as i said last april,
> as an engineer, i sympathize with the excitement that the protocol
is
> very extensible. otoh, an architect might view that the protocol is
> merely a list of name/value tuples to indicate a lack of bounding and
> understanding of the problems and/or inability to make a real design
for
> it.
>
> open loop extensibility is really worrying
the iesg.
---
and we discussed again in may:
> So,
the WG questioned whether the specs could be more relax on the
> IANA
requirements for extensibility. Specifically, could a
> vendor-specific
extension be created without Standards Action.
i can see arguments for
relaxing to info but not iana-only. a
documentation trail is needed.
---
and a number of iesg members made quite clear, or at least
tried to, that
any extensions, vendor or otherwise, must require previous
documentation
in an rfc.
---
please consider this a bug
report. my apologies for not knowing how to
get a bug number etc.
Submitter name: Randy Bush
Submitter email address:
randy@psg.com
Date first submitted: 2001.09.03
Reference:
Document:
base
Comment type: E
Priority: S
Section: 1.0, 1.1
Rationale/Explanation of issue:
The Introduction (section 1.0) talks
about the history and motivation for
the development of Diameter. Section
1.1 talks about the basic building
blocks of Diameter. Section 2 provides an
overview of protocol
concepts. What would be helpful is if a high-level
introduction could
be provided within section 1. The material currently in
section 1.1 might
be better moved to section 2.
Requested change:
To provide context, the following topics would be useful in the
Introduction:
a. An overview of the Diameter approach
1.
Relationship of NASes, Servers and Intermediaries
2. Message routing
concepts
3. Requests, Responses, Unsolicited messages
b. Important
ways that Diameter differs from RADIUS
(Idea is to introduce the concepts,
not go into
depth, but make clear what the feature is attempting
to
achieve. Reference where details are provided.)
1. Peer-to-peer nature
2. Explicit support for intermediaries
3. Connection-oriented versus
connectionless
4. Concept of extensions
5. Built-in failover support
6. Larger attribute space
7. Integrated accounting
8. Mandatory bit
9. Application-layer ACKs and error messages
10. Unsolicited server
messages
11. Peer discovery
12. Capabilities negotiation (worth
explaining why
this isn't e2e here)
c. Description of the Diameter
document set and relationship
between the documents.
d. Approach to
extensibility (this is in section 2.3, but might
be better consolidated into
the Introduction)
From: Dilip
Date: Mon Dec 24 11:33:25 2001
Reference:
http://www.angelfire.com/in/dilris
Hi
In the peer state machine
section 5.6.2 Events.
The Rcv-Message Event states
"A message other than
CER,CEA,DWR, or DWA was
received"
In THIS definition DPR & DPA is
missed out.
suggestion
---------
Sections 5.6.2 Events should
have
Rcv-Message " A message other than
CER,CEA,DPR,DPA,DWR, or DWA was
received"
Regards
Dilip Patel
Issue 271: Sections 9.4 and 8.2 are in conflict.
Submitter: Jari Arkko <jari@arkko.com>
Date: January 3,
2002
Reference:
Document: BASE-08
Comment type: T
Priority: S
Section: 8.2
Rationale/Explanation of issue:
Sections 9.4 and 8.2
are in conflict.
The former requires clients to store acct
records during
network outage, and the
latter requires immediate sending.
The
specification is also silent on
how the client devices know whether
it
should grant access during times
of network outages towards the
accounting
server. I can imagine that in some
cases we would like to stop
services if
we can't provide real-time accounting,
while in some other
cases we would like
to continue.
Furthermore, the state machine in
8.2
(as well as the one that I just posted)
does not specify what to do
when things
happen to the session faster than what it
takes for an ack to
come back from the server.
For instance, what should we do if the
session
is terminated while we are still waiting for
the start
ack?
Proposed change:
An AVP similar to the
Accounting-Interim-Interval
could be used to control whether access should
be
granted or discontinued upon problems in sending
the accounting
records.
The state machine must be modified to consider what
to do
with session termination and interim record
generation while we are still
waiting to send previous
data.
9.8.x. Accounting-Realtime-Required
AVP
The Accounting-Realtime-Required AVP (AVP Code TBD) is of
type
Enumerated and is sent from the Diameter home authorization server
to
the Diameter client. The client uses information in this AVP to
decide
what to do if the sending of accounting records to the
accounting server has
been temporarily prevented due to,
for instance, a network
problem.
DELIVER_AND_GRANT 1
The AVP with Value field set to
DELIVER_AND_GRANT means
that the service MUST only be granted as long as
there is
a connection to an accounting server. Note that the set
of
alternative accounting servers are treated as one server
in this sense.
Having to move the accounting record stream to a
backup server is not a
reason to discontinue the service
to the user.
GRANT_AND_STORE
2
The AVP with Value field set to GRANT_AND_STORE means that
service
SHOULD be granted if there is a connection, or as
long as records can still
be stored as described in section
9.4.
This is the default behaviour
if the AVP isn't included
in the reply from the authorization
server.
GRANT_AND_LOSE 3
The AVP with Value field set to
GRANT_AND_LOSE means
that service SHOULD be granted even if the records
can
not be delivered or stored.
8.2. Accounting State
Machine
Add the following new entries:
PendingE Failure to send
and buffer Store Idle
space available Event
Record
PendingE Failure
to send and no buffer Idle
space available
PendingS Failure to send
and buffer Store Open
space available and realtime Start
not equal to
DELIVER_AND_GRANT Record
PendingS Failure to send and no buffer
Open
space available and realtime
equal to GRANT_AND_LOSE
PendingS Failure to send and no buffer Disconnect Idle
space
available and realtime user/dev
not equal to GRANT_AND_LOSE
PendingI
Failure to send and (buffer Store Open
space available or old record
Interim
can be overwritten) and Record
realtime not equal
to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer
Open
space available and realtime
equal to GRANT_AND_LOSE
PendingI Failure to send and no buffer Disconnect Idle
space
available and realtime user/dev
not equal to GRANT_AND_LOSE
PendingD
Failure to send and buffer Store Idle
space available
Stop
Record
PendingD Failure to send and no buffer Idle
space
available
Idle Records in storage Send
PendingB
record
PendingB Successful accounting answer Delete
Idle
received record
Submitter name: Juha-Pekka Koskinen
Submitter
email address: juha-pekka.koskinen@nokia.com
Date first submitted: January
31, 2002
Reference: draft-hakala-diameter-credit-control-01.txt
Document:
Base (draft-ietf-aaa-diameter-08.txt)
Comment type: T
Priority:
1
Section: 9.5 and 9.8.1
Rationale/Explanation of issue:
There
are two different kind of accounting sessions used for charging
purposes.
The postpaid accounting session is established to transfer CDRs
(Charging Data Records) from client to server. These CDRs are used for billing
purposes, typically once a month. The transfer of the CDRs is not critical task
from the communication session point of view. The CDRs could be transferred only
when the communication session has been disconnected, so the actual postpaid
accounting session doesn't need to be fully completed simultaneously with the
communication session.
The prepaid accounting session is established to
transfer charging information from client to server for rating purposes. The
cost of the communication session is calculated and according to these
calculations money is reserved from subcribers account. If there is no credit
left in subscribers account or the credit is used during the communication
session, the prepaid accounting session will be terminated. That termination
will also cause the termination of the communication session.
Requested
change:
Proposal
As these two accounting sessions has different
logic, it would be very useful to specify new values used in
Accounting-Record-Type AVP (Chapter 9.8.1):
EVENT_PREPAID 5
An
Accounting Event Prepaid record is used to indicate that one-time prepaid event
has occured (meaning that the start and end of the event are simultaneous). This
record contains all information relevant to service and granted
threshold.
START_PREPAID 6
An Accounting Start Prepaid record is used
to indicate that a prepaid service will have measurable length. An Accounting
Start Prepaid record is used to initiate that money reservation will be needed
for this session. This record contains all information that is relevant to
determine cost of the service and granted threshold.
UPDATE_PREPAID
7
An Accounting Update Prepaid record is used to indicate that a prepaid
service will need more credit to continue. It is also used when service (client)
need to update itself tariff of the ongoing accounting session. This record
contains all information that is relevant to determine cost of the service and
granted threshold.
STOP_PREPAID 8
An Accounting Stop Prepaid record is
sent to terminate and prepaid accounting session. This record also contains
unused amount of the granted threshold.
Also the chapter 9.5 should have
following structure:
9.5 Accounting Records
In all accounting
records the Session-Id and User-Name AVPs MUST be
present. If strong
authentication across agents is required, as
described in [11], the
CMS-Signed-Data AVP may be used to
authenticate the Accounting Data and
Service Specific AVPs. It is not
typically necessary that the CMS-Signed-Data
AVP cover any additional
AVPs, but it is permitted as long as the AVPs
protected are defined
to have their 'P' bit set.
9.5.1 Postpaid
Accounting Records
Different types of postpaid accounting records are
sent depending on the
actual type of accounted postpaid service and the
accounting server's
directions for interim accounting. If the accounted
postpaid service is a one-
time event, meaning that the start and stop of the
event are
simultaneous, then the Accounting-Record-Type AVP MUST be present
and
set to the value EVENT_RECORD.
If the postpaid accounted service
is of a measurable length, then the AVP MUST
use the values START_RECORD,
STOP_RECORD, and possibly,
INTERIM_RECORD. If the accounting server has
directed interim
accounting to be enabled for the session, but no interim
interval was
specified, two accounting records MUST be generated for each
service
of type session. When the initial Accounting-Request is sent for
a
given session is sent, the Accounting-Record-Type AVP MUST be set to
the
value START_RECORD. When the last Accounting-Request is sent, the
value MUST
be STOP_RECORD.
If a specified interim interval exists, the Diameter
client MUST
produce additional records between the START_RECORD and
STOP_RECORD,
marked INTERIM_RECORD. The production of these records is
directed
both by Accounting-Interim-Interval as well as any
re-authentication
or re-authorization of the session. The Diameter client
MUST
overwrite any previous interim accounting records that are
locally
stored for delivery, if a new record is being generated for the
same
session. This ensures that only one pending interim record can
exist
on an access device for any given session.
A particular value of
Accounting-Sub-Session-Id MUST appear only in
one sequence of accounting
records from a DIAMETER client, except for
the purposes of retransmission.
The one sequence that is sent MUST
be either one record with
Accounting-Record-Type AVP set to the value
EVENT_RECORD, or several records
starting with one having the value
START_RECORD, followed by zero or more
INTERIM_RECORD, and a single
STOP_RECORD. A particular Diameter application
specification MUST
define the type of sequences that MUST be
used.
9.5.2 Prepaid Accounting Records
Different types of prepaid
accounting records are sent depending on the
actual type of accounted prepaid
service and the accounting server's
directions for interim accounting. If the
accounted prepaid service is a one-
time event, meaning that the start and
stop of the event are
simultaneous, then the Accounting-Record-Type AVP MUST
be present and
set to the value EVENT_PREPAID.
If the prepaid
accounted service is of a measurable length, then the AVP MUST
use the values
START_PREPAID, STOP_PREPAID, and possibly,
UPDATE_PREPAID. When the
accounting server has granted threshold value
to used for the session, but
the granted threshold is not used completely or the
client's tariff doesn't
change, two accounting records MUST be generated for each
service of type
session. When the initial Accounting-Request for a
given session is sent, the
Accounting-Record-Type AVP MUST be set to
the value START_PREPAID. When the
last Accounting-Request is sent, the
value MUST be STOP_PREPAID.
When
granted threshold value is used up or the client's tariff will change,
the
Diameter client MUST produce additional records between the START_PREPAID and
STOP_PREPAID records, marked UPDATE_PREPAID. The production of these records
is directed
both by Accounting-Interim-Interval, application specific AVP
concerning granted
threshold as well as any re-authentication or
re-authorization of the session. The
Diameter client MUST produce
UPDATE_PREPAID record when granted threshold is used up.
A particular
value of Accounting-Sub-Session-Id MUST appear only in
one sequence of
accounting records from a DIAMETER client, except for
the purposes of
retransmission. The one sequence that is sent MUST
be either one record with
Accounting-Record-Type AVP set to the value
EVENT_PREPAID, or several records
starting with one having the value
START_PREPAID, followed by zero or more
UPDATE_PREPAID, and a single
STOP_PREPAID. A particular Diameter application
specification MUST
define the type of sequences that MUST be used.
Submitter name: John Loughney
Submitter email address:
john.loughney@nokia.com
Date first submitted: 18 Feb 2002
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
3
Rationale/Explanation of issue:
DNS SRV-related text in Base needs
to be updated to reflect latest SIP
discovery draft.
Requested
change:
Proposal
Review the current draft, draft-ietf-sip-srv-04.txt
and summarize the text.
Proposed text forthcoming.
John
Date: Tue Feb 05 08:44:20 2002
In
draft-ietf-aaa-diameter-08.txt, Section 5.2, item 3, it defines how to
use
DNS SRV to lookup diameter peers.
However, there is no way to specify
security when locating a peer. (And, you
need to know in advance if the peer
is using TLS).
So, I prepose the following text be added to the base
draft to clarify using
DNS
SRV.
_diameter._tls_sctp.domain.org
_diameter._tls_tcp.domain.org
Right
now, there is
just:
_diameter._tcp.domain.org
_diameter._sctp.domain.org
I
have not looked into CMS closely, but there might be more additions for
CMS.
Since IPSEC is done at the ip layer, I think we can ignore that.
(The tunnel
has to be set up by administrators prior to any connections being
made)
Later,
-Dave
From:
David Frascone
Date: Tue Feb 05 16:03:34 2002
An EXTREMELY minor nit
. . .
But . . .
AAA should be defined in the terminology sections
of all drafts. (The acronym
is never broken down)
-Dave
Submitter name: Bob Kopacz
Submitter email address:
BKopacz@InterlinkNetworks.com
Date first submitted: 02-06-2002
Reference:
Document: base-08
Comment type: Technical
Priority: 1
Section: 8.1
Rationale/Explanation of issue:
I believe there is
an error in the "Authorization Session State
Machine", in section 8.1 of the
base draft, in the 1st state machine
which represents the case where the
server maintains session-state.
If, for a session in OPEN state, the
server wants the session to be be
terminated, it sends an ASR and goes into
DISCON state. When the ASA
is received, the server goes into IDLE state. The
state/events I am
referring to are:
| The following state machine is
used when state is maintained on the
| server:
|
| State Event Action
New State
|
-------------------------------------------------------------
|
| Open
Home server wants to send ASR Discon
| terminate the service
|
|
Discon ASA Received Cleanup Idle
This seems not quite right for a few
reasons.
(1) When the server subsequently receives the follow-up STR from
the
access device, the session will be either non-existent or in
IDLE
state.
(2) An ASR is only a request to terminate a session. It
doesn't
really go away until the session-timeout expires,
the
authorization-lifetime expires, or the access device sends an STR.
So
sending an ASR should not affect the server's state (OPEN),
and
receiving an ASA should in general not affect the server's
state
(OPEN).
(3) The state machine doesn't take into account the
Result-Code
returned in the ASA. The draft indicates that an access device is
not
required to honor an ASR, i.e. the access device can just reply
with
"unable to comply" and not terminate the session. In this case
the
server would have incorrectly terminated an active session when
receiving the negative ASA.
When an ASR is sent, the Result-Code
values likely to be returned in
the ASA are:
SUCCESS -- This means
that the access device will be following the
ASA with an STR, so the server
can just wait for the STR.
UNABLE_TO_COMPLY -- The access device has no
intention of terminating
the session.
UNKNOWN_SESSION_ID -- The access
device doesn't know about this
session. Somehow the access device and server
have gotten out of
sync. The server can go ahead an clean up this phantom
session.
UNABLE_TO_DELIVER -- The ASR never made it to the access device,
so
the access device won't be terminating this session, if it
even
exists.
Requested change:
Replace the two
entries:
| State Event Action New State
|
-------------------------------------------------------------
|
| Open
Home server wants to send ASR Discon
| terminate the service
|
|
Discon ASA Received Cleanup Idle
With:
| State Event Action New
State
| -------------------------------------------------------------
|
| Open Home server wants to send ASR Open
| terminate the service
|
| Open ASA Received Cleanup Idle
| with Result-Code
| =
UNKNOWN-SESSION-ID
|
| Open ASA Received None Open
| with Result-Code
(ignore)
| not = UNKNOWN-SESSION-ID
|
| Not ASA Received None No
Change.
| Open
Notes on the above four entries (this is FYI, not
part of draft):
Entry#1. The ASR doesn't do anything on its own, so just
stay
in OPEN state and wait for the ASA.
Entry#2. This is the case
where the server is out of sync with the access
device. This is a phantom
session that the server can remove.
Entry#3. If SUCCESS, the access
device will soon send an STR, which
will terminate the session. If not
SUCCESS, the access device won't
be terminating the session, so it stays
active.
Entry#4. Here something happened to the session between the time
the
ASR was sent and the ASA was received.
Submitter name: Tony Johansson
Submitter email address:
tony.Johansson@ericsson.com
Date first submitted:
02-07-2002
Reference:
Document: cms-03
Comment type:
Technical/Editorial
Priority: 1
Section: 1.6
Rationale/Explanation of
issue:
In the discussion and proposed solution to Issue 266 -
Returning
AAAF-Generated FA-HA Key to FA (please find detailed background
info in
http://www.merit.edu/mail.archives/aaa-wg/msg02986.html message
thread)
we have identified the need to be able to issue DSA messages between
two
AAA(F) servers, where none of the nodes belong to the same realm as
the
user being authorized.
This seems to be okay and straight forward
according to the CMS
application except for what is stated in section
1.6.
“However, it is important to note that one of participants of a
DSA
(specifically the one in the home network) MUST belong to the same
realm
as the user being authorized (the realm portion of the Network
Access
Identifier found in the User-Name AVP), otherwise an answer is
returned
with the Result-Code AVP set to
DIAMETER_AUTHORIZATION_REJECTED.”
The CMS application describes how a
security association is established
by two peers through agents, and how
authentication, integrity,
confidentiality and non-repudiation (with proof of
origin) are achieved
using a mixture of symmetric and asymmetric transforms,
by encapsulating
CMS data within AVPs. Thus, the nature of this application
deals with
servers and not users. Do really have to bring in user
authorization as
described in section 1.6?
Requested
change:
Remove section 1.6, so that the CMS application only talks
about
security association establishment between peers, encryption of
AVPs
between peers, etc.
1.7 is now 1.6, a new 1.7 was added to clarify something that
came up
during editing.)
Submitter name: Jari Arkko (Sebastian
Zander)
Submitter email address: jari@arkko.com
Date first submitted: Feb
10, 2002
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg03001.html
Document: base,
nasreq
Comment type: E
Priority: 2
Section: 9.5, 9.7.1, 9.7.2, nasreq
10.2
Rationale/Explanation of issue:
Section 9.5 of base-08 reads: "In
all accounting records the
Session-Id and User-Name AVPs MUST be present.".
However, the Diameter node
sending the accounting request may not know it.
Still the target can use the various
session-ID AVPs to correlate the
records. There also seems to be some inconsistency
in the draft and between
base-08 and nasreq-08: In section 9.7.1 & 9.7.2
(ACR, ACA definition)
User-Name AVP is marked as optional while in
section 10.2 it is again
specified as MUST.
Proposed change:
I suggest modifying 9.5 so
that it reads. "User-Name AVP MUST be present if
it is available to the
Diameter client."
Then change the tables in 10.2 as
follows:
User-Name | 0+ | 0+ |
Submitter name: Jari
Arkko
Submitter email address: jari@arkko.com
Date first submitted: Feb
10, 2002
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg03003.html
Document:
cms
Comment type: E/T
Priority: 2
Section: 1, 1.3,
7.1
Rationale/Explanation of issue:
People who have read the CMS
document do not clearly understand
that PDS mechanisms are not intended to
create actual security
associations, but just to offload the computations to
someone else.
Secondly, the document does not explain what to do in
case
NO_CMS_THROUGH_PROXY is maliciously returned from somewhere
else than
in our own domain.
Thirdly, there's some spelling
problems.
Requested change:
Change
> This specification
contains two different set of messages. The DSA
> messages are used to
establish a security assocation, while the PDS
> messages are used to
request that a security association be
> established by a third
party.
to
This specification contains two different set of
messages. The DSA
messages are used to establish a security assocation, while
the PDS
messages are used to request that a security association
be
established by a third party. The security association established
using
DSA is used end-to-end for Diameter signaling, even through proxies
that
may exist in between. In constrast, where PDS messages are used,
Diameter
signaling is protected as usual only hop-by-hop between the client
and
the proxy handling CMS security on its behalf. From there onwards
to
the Diameter server, end-to-end protection is then used.
Also in
1.3, "recelived" => "received". And just before the end of
1.3, the last
"MAY" => "might".
In 1.3, just before "If a DSA for a given realm
cannot be established...",
add a new paragraph:
A proxy MAY both allow
CMS security through itself and it
can offer CMS services to the clients
connecting to it. This
would be useful in networks where some clients wish to
use
CMS security themselves, and some others need the proxy to
assist
them. However, it is necessary to prevent misconfigured
clients from
inappropriately sending PDS messages to nodes
further onwards in the network,
as this would leaeve the
Diameter messaging without CMS protection when it
leaves the
proxy. For this reason, the
DIAMETER_NO_CLEARTEXT_THROUGH_PROXY
MUST be returned for PDS messages where
Destination-Realm
is not the proxy itself. This also ensures that rogue
nodes
further onwards in the network can not return
DIAMETER_NO_CMS_THROUGH_PROXY
in an attempt to bypass security
mechanisms.
And then add to section
7.1:
DIAMETER_NO_CMS_THROUGH_PROXY 4014
This error code is
returned when a non-transparent proxy
receives an PDSR message to
Destination-Realm that is
not the proxy itself, and the proxy requires CMS
security
to be applied for all traffic leaving it.
"People who have
read the CMS document do not clearly understand
that PDS mechanisms are not
intended to create actual security
associations, but just to offload the
computations to someone else."
I tried to clarify the text in various
places.
"Secondly, the document does not explain what to do in
case
NO_CMS_THROUGH_PROXY is maliciously returned from somewhere
else than
in our own domain."
I think that (some of?) the requested text was added
prior
to me taking over as editor. I think that this is also affected
by
the resolution of 221/291, but could well warrant
additional
clarification.
"Thirdly, there's some spelling
problems."
Dun doze:-)
Submitter name: Jari Arkko (Sebastian
Zander)
Submitter email address: jari@arkko.com
Date first submitted: Feb
10, 2002
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg03001.html
Document: cms,
base
Comment type: E
Priority: 2
Section: base 4.6, cms 2.0, 3.1,
5.0
Rationale/Explanation of issue:
1) Base does not sufficiently
explain what 'MAY encrypt' means in
the AVP tables. Does it mean that it
where CMS is used for the
particular message, the AVPs MAY be encrypted, or
does it mean
that if CMS is used, they MUST be encrypted?
2) CMS flow
example in 5.0 is misleading as to how the
set of protected AVPs is
decided.
3) There are several references to somehow negotiating
the
AVPs to be signed/encrypted. We have removed such
functionality since this is
really static information.
Proposed change:
1) Add to the
end of the first paragraph in base 4.6: "If an
AVP MAY be encrypted, section
2.0 of the Diameter CMS security extension [11]
defines in which situations
the encryption is actually employed."
Move the last paragraph of 3.1 to
the end of 2.0, where I
think it would be easier to find.
In cms 3.1,
change the text ", which specifies which AVPs
should be encrypted, signed or
both, as well as which public
key(s) to use." to ", which specifies which
public key(s)
to use for signing and encryption of AVPs."
Also, in cms
5.0, remove the last sentence of step (f). And
the last sentence of
(g).
In step (h) change "which authenticates the AVPs that
were
requested by the Home Server in the DSAA." to "which
authenticates
the AVPs that MUST be authenticated as defined in section
2.0."
In step (i) change "whose contents include the AVPs that
were
specified by the NAS in the DSAR." to "whose contents include
the
AVPs that MUST be encrypted as defined in section
2.0."
Resolution: The resolution to both issues #221 and #279 was
to remove the expected-* AVPs
from CMS, and change the defintion of "MAY
Encr" in both base and CMS. The agreed change in the CMS I-D is at the end
of
section 3.1:
"Note: [BASE] includes the "MAY encr" column when describing
AVPs. For
the originator "MAY encr" as used in [BASE] means that if a
message
containing that AVP is to be sent via a proxy/agent (as opposed
to
directly) then the message MUST NOT be sent unless there is a
DSA
between the originator and the recipient OR the originator has
locally
trusted configuration that indicates that CMS need not be
used."
Submitter name:
Sebastian Zander
Submitter email address: zander@fokus.fhg.de
Date first
submitted: February 11th, 2002
Reference:
http://www.merit.edu/mail.archives/aaa-wg/msg02998.html
Document:
base-08
Comment type: T
Priority: 1
Section: 9.5, 10.2
Rationale/Explanation of issue:
Section 9.5 of base-08 reads:
"In all accounting records the Session-Id and User-Name AVPs MUST be
present."
The Diameter client may not know the user's identity. Therefore
there can not be a
MUST for including it. Furthermore there is some
inconsistency in the draft since the
User-Name AVP is already marked
optional in section 9.7.1 and 9.7.2 but mandatory
in section
10.2.
Requested change:
Section 9.5 should be changed to:
"In
all accounting records the Session-Id AVP MUST be present. The User-Name AVP
MUST be present if it is available to the Diameter client."
The table
in section 10.2 should be changed so that User-Name is optional.
--
Sebastian
Submitter name: Kevin Purser
Submitter email address:
kevin.purser@ericsson.com
Date first submitted: February 11th,
2002
Reference: none
Document: base-08alpha02
Comment type:
Editorial
Priority: 1
Section: 5.6 "Peer State
Machine"
Rationale/Explanation of issue:
There are a couple of
references in this section to "the state machine
described in [52]". However,
in the latest version of the transport draft,
such a state machine is not
present.
Requested change:
Remove these references in the
text.
Submitter name:
Kevin Purser
Submitter email address: kevin.purser@ericsson.com
Date first
submitted: February 14th, 2002
Reference: none
Document:
base-08alpha02
Comment type: Technical
Priority: 1
Sections: 2.9.3,
6.12
Rationale/Explanation of issue:
Diameter redirect agents
currently provide realm to server address
resolution. Within a single
administrative domain, it could be useful to
allow redirect agents to have
the option of providing user to server address
resolution.
Requested
change:
* change the first paragraph of section 2.9.3 to
read:
Redirect agents provide Realm to Server address resolution and MAY
also
provide User to Server address resolution. These redirect agents would
make
use of the Diameter routing table or optionally, a user table to
determine
where a given request should be forwarded. When a request is
received by a
redirect agent, a special answer is created, which includes the
identity of
the Diameter server(s) the originator of the request should
contact
directly.
* add the following enumerated value in section
6.12:
ALL_USER 6
All messages for the user requested MAY be sent to
the
host specified in the Redirect-Host AVP.
Submitter
name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: 18 Feb 2002
Reference:
Document: Base
Comment type: T
Priority: 1
Section: 2.2
Rationale/Explanation of
issue:
Usage of TLS and IPsec. Aside from more detail on how to use TLS
and
IPsec, it was noted that the drafts do not say that IPsec is
for
Intra-domain use and TLS for inter-domain. In practice, IKE isn't
very
interoperable when used with certs, and can't support the required
cert
policies very well. TLS has this nailed. Should we say
that IPsec is
primarily for use with pre-shared keys and only
intra-domain, and TLS is for
cert usage and inter-domain? Should we
adjust the language (TLS as MUST on
client, too?) Issue to be filed and
raised on the mailing
list.
Requested change:
Proposal
Add the following
text:
Diameter clients, such as Network Access Servers (NASes) and
Mobility
Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS
[TLS].
Diameter servers MUST support TLS and IPSec. Operating the Diameter
protocol without any security mechanism is not recommended.
It is
suggested that IPsec is primarily for use with pre-shared keys
and to
protect intra-domain traffic. TLS is for certificate usage and
to project
inter-domain traffic.
John
Submitter name: Paco Marin
Submitter
email address: fmaring@airtel.es
Date first submitted:
02-18-2002
Reference:
Document:
draft-hakala-diameter-credit-control-01.txt
Comment type:
Technical
Hi all,
I've been taking look to the last
version of the draft 'Diameter Credit Control
Application'
(draft-hakala-diameter-credit-control-01.txt). I've been
thinking about common services an operator
like my company needs to offer and
the possibility of applying DIAMETER CCA to the charging part.
Sorry if some
of the following issues are obvious, but I think despite of the most of the
scenarios
being covered with the described protocol, however I did'nt find
the way to use this protocol to
cover two possible scenarios. The referred
scenarios are the following:
1.- Check of balance.
Sometimes is
necessary to check if there is enough balance to grant a service to a
subscriber.
Imagine a subscriber of a mobile comunications operator wants to
download a melody or a 'logo' from
the Internet on his mobile phone (using
the Short Message Service of GSM). In this scenario, there
are three parts:
the subscriber, the network operator and a third party which is the
service
provider. The third party will charge the sent melody (or logo) to
the network operator just when
the network operator receives it, so it could
be interesting to acknowledge the Short Message
delivery from the third party
only when the subscriber has enough credit. This way the operator
avoids to
pay for a message that will never be delivered because the final user (the
subscriber) has
no credit enough. I've been thinking about the possibility of
using 'session based credit control'.
However is hardly ineficient, the SM
must be acknowledged immediately and the short message could
wait several
days to be delivered to the final user (the user could be out of coverage), it
implies
to keep the session opened until the SM is finally
delivered.
2.- Increment of Credit
In some scenarios could be useful
to add to the protocol the posibility to increase the balance
instead of
decrementing it. As an example, could be a way to motivate the user access
to
advertisement information in the internet or to receive adversiting Short
Messages from a third
party. In these scenarios could be interesting to be
able to increment the credit directly from the
client, as an example increase
money on the user account or allow 1 free short message every 5
advertisement
Short Message received.
I think there is no way to make it with the
current version of the draft (please, please, please
correct me if I am wrong
or confused).
The solution to these two scenarios should not be
fundamental for the overall working of the
Diameter CCA, however it would
apply flexibility enough to ease the use of the protocol to the
legacy
architectures of the current network operators.
In my humble
opinion a possible solution for both scenarios should be to include a new
AVP.
PROPOSAL OF SOLUTION
A new AVP to indicate an
operation on the balance is going to be accomplished could be added to
the
proposed AVPs of the Diameter CCA protocol. This AVP could indicate if
the action to be carried out
is a decrement, check of balance or an
increment. If this new AVP is not included in the request,
the server should
consider that the value of this one is '0', it will mean the behaviour of
the
protocol will be the one described up to now. The new AVP could
be:
'Balance-Management-Indicator', it should be of tipe Unsigned32 and
its values could be:
'0': Decrement, the request and answer work as up to
now. The 'Requested-Service-Unit' AVP
contains the unit to decrement, the
'Granted-Service-Unit' AVP contains the service units granted.
This units
will be decremented in that moment from the user account.
'1':Check of
balance, the 'Requested-Service-Unit' AVP could contains the service unit to
check
if it is allowed to be carried out, the 'Granted-Service-Unit' AVP
contains the service units
allowed to be carried out. This units will NOT be
decremented from the user account.
'2': Increment, the request and answer
work in a similar way as described for the value '0'.
The
'Requested-Service-Unit' AVP contains the unit to increment, the
'Granted-Service-Unit' AVP
contains the service units incremented. This units
will be incremented in that moment in the
user
account.
The accounted AVP table should be modified
as follows:
+----------+
| Command |
| code
|
+----+-----+
Attribute Name |ACR | ACA
|
------------------------------+----+-----+
Balance-Management-Indicator
|0-1 | 0
|
------------------------------+----+-----+
Maybe I'm
confused..... correct me in that case.
Thanks a lot.
Paco.
From: Tony Johansson
Date: Tue Feb 19 14:30:15 2002
All,
In my efforts to update the Diameter MIPv4 application I
have stumble on
the Accounting AVPs defined and realized that exactly the
same AVPs are
defined also in the NASREQ application, see
below.
Unless I have misunderstood something, I would suggest that we
move
these AVPs to the Base, since they are used by both NASREQ and
MIP.
Regards,
/Tony
In MIP:
"7.1
Accounting-Input-Extended-Octets AVP
The Accounting-Input-Extended-Octets
AVP (AVP Code 363) is of type
Unsigned64, and contains the number of octets
in IP packets received
from the user.
7.2
Accounting-Output-Extended-Octets AVP
The
Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type
Unsigned64,
and contains the number of octets in IP packets sent to
the
user.
7.3 Accounting-Session-Time AVP
The
Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32,
and
indicates the length of the current session in seconds.
7.4
Accounting-Input-Extended-Packets AVP
The
Accounting-Input-Extended-Packets (AVP Code 365) is of type
Unsigned64, and
contains the number of IP packets received from the
user.
7.5
Accounting-Output-Extended-Packets AVP
The
Accounting-Output-Extended-Packets (AVP Code 366) is of type
Unsigned64, and
contains the number of IP packets sent to the user."
In
NASREQ:
8.1 Accounting-Input-Extended-Octets AVP
The
Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
Unsigned64,
and contains the number of octets in IP packets received
by the
user.
8.2 Accounting-Output-Extended-Octets AVP
The
Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type
Unsigned64,
and contains the number of octets in IP packets sent to
the
user.
8.3 Accounting-Session-Time AVP
The
Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32,
and
indicates the length of the current session in seconds.
8.4
Accounting-Input-Extended-Packets AVP
The
Accounting-Input-Extended-Packets (AVP Code 365) is of type
Unsigned64, and
contains the number of IP packets received by the
user.
8.5
Accounting-Output-Extended-Packets AVP
The
Accounting-Output-Extended-Packets (AVP Code 366) is of type
Unsigned64, and
contains the number of IP packets sent to the user.
From:
Tony Johansson
Date: Tue Feb 19 17:40:02 2002
All,
Section
4.11 in the Diameter MIPv4 appl. defines the MIP-Home-Agent-Host
AVP and
contains the identity of the home agent requested by the mobile
node in its
registration request. This AVP is used by the AAAH to
determine the
destination of the HAR.
However, this AVP demands changes to the Mobile
IP protocol and looking
back at the Issue 212
thread
(http://www.merit.edu/mail.archives/aaa-wg/2001-11/msg00062.html)
the
consensus was to NOT make use of this AVP. The agreed solution for
Issue
212 was instead to require that the new AAAH perform the
Server
Discovery procedures (defined in the Base) to determine the URL of
the
Home Agent.
So, I believe this AVP is an editorial mistake and
should just be
removed. Any objections to
this?
Regards,
/Tony
Submitter name:
David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date
first submitted: 2/21/02
Reference:
Document: Base
Comment type:
T
Priority: S
Section: 4.4
Rationale/Explanation of issue:
Some
Background
---------------
The AAA URI provides two different kinds of
information.
1. It identifies a Diameter node. A Diameter node is a
Diameter
process running on some host or device. It is possible to
have
more than one Diameter process running on a host.
2. It provides
information about how to connect to the Diameter node
-- what transport
protocol to use, what transport level security
to use, and even what AAA
protocol to use (although we are only
concerned about one, namely
Diameter).
The AAA URI also serves two different purposes.
1. It
is used in the peer-to-peer protocol to identify a peer and
indicate certain
parameters concerning how to connect to that
peer. This use requires the full
URI including the prefix, the
fqdn, the port number, and the options. A URI
for this purpose
may be stored in a local configuration file or on a remote
server
to enable dynamic peer discovery (see sec. 5.2).
2. It is used
in the Diameter routing and forwarding decisions to
identify the Diameter
node to which a Diameter message is
addressed. This use requires those
portions of the URI that
identify the Diameter node but does not require (and
can be
confused by) the information about how to connect to the node as a
=
peer. This is the use made of the URI as transmitted in all AVPs
of
type DiameterIdentity.
The Problem
-----------
The problem
is that the URI format is currently defined in only one
place (sec. 4.4 under
the "DiameterIdentity" type) and makes no
distinction between its use for the
two different purposes described
above.
Operational Difficulties
if the Problem Isn't
Fixed
---------------------------------------------------
Section 4.4
states:
Unless a Diameter node is sitting on the border of two
routing
domains (e.g. private and public), a Diameter node MUST
advertise
the same identity on all connections, via the CER
and CEA's Origin-Host
AVP.
Suppose a Diameter node has two peers. It connects to the first
peer
using SCTP. It connects to the second peer using TCP. In order
to
obey this requirement, the node would have to include the
string
"transport=sctp" in the Origin-Host AVP it puts in its CER or
CEA
message to the second peer even though it is using TCP to connect
to
that peer. So the identity advertised is not the identity used.
This
seems odd, but as we shall see, it is actually necessary in order
to make the
routing mechanism work.
Section 4.4 goes on to state:
The same
identity advertised in a connection's CER and CEA MUST
be used in any AVP of
type DiameterIdentity sent on that
connection.
Now suppose an
implementor misses the oddity required by the first
sentence and does the
obvious thing -- suppose the implementation
always includes in the CER the
parameters actually in use on the peer
connection. Then the implementation
will have a very hard time
meeting this requirement too. It would have to
know how it will
route the message at the time it generates the message, a
horrible
violation of modularity. Supposing it does know how it will
route
the message and sets the value of the Origin-Host AVP in the
message
to the same value used in the CER or CEA sent to the peer to which
it
will route it. Now suppose something goes wrong when sending
the
message to this peer, and the message is subsequently retransmitted
to
a backup peer. Oops. Now the Origin-Host AVP is wrong for that
connection and
it can't be changed.
So we'll just have to assume that all implementors
pick up on the
oddity. But wait -- we're still not out of the woods. Suppose,
at
the time a session begins, the Diameter client supporting the
session
uses TCP on its peer link. So it includes the string
"transport=tcp"
in the auth request that begins the session. Suppose that
several
hours later the session is still in progress, but the client
has
reinitialized its peer link and is now using SCTP. Now suppose
the
home server sends an Abort-Session-Request message to the client
for
this session. The Abort-Session-Request will include
a
Destination-Host AVP that contains the string "transport=tcp".
The
message eventually reaches the peer connected to the client. The
peer
matches the URI in the Destination-Host AVP with the ones in its
peer table.
It finds no match because "transport=tcp" does not match
"transport=sctp". So
it discards the message.
Interaction With Issue
273
--------------------------
Another issue urges that Diameter nodes
not use different port
numbers for TLS versus non-TLS connections. I am
guessing that issue
273 is the one that encompasses this change. The question
of port
number use for TLS versus non-TLS was raised by Allison Mankin
in:
http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00025.html
The
outcome of issue 273 (if that is the issue that includes this
question) is
critical to the resolution of this issue as well. The
reason is that we use
the combination of fqdn and port number to
identify a diameter node. If more
than one Diameter node (Diameter
daemon) runs on a host, they will use
different port numbers. But if
a Diameter node listens on more than one port
number, then it may use
two different URIs and there will be no way for a
peer to know that
the URI from the Destination-Host AVP of a message it is
routing
matches the URI of one of its peers if the port number
differs.
John Loughney suggested use of aaa: vs. aaas: to indicate
whether TLS
is used
in:
http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html
If
this suggestion is adopted, then the "s" in aaas: will need to be
ignored
when doing routing matches against entries in the peer
table.
Requested change:
Define the format of the URI
somewhere other than section 4.4. In
the definition of the DiameterIdentity
type in section 4.4, specify
that only the prefix, fqdn, and port number
portions of the URI are
included in AVP value fields of this type. The
sentences cited above
may now be left in section 4.4 because they no longer
cause a
problem.
If the resolution of issue 273 allows a Diameter node
to listen on
different ports for TLS vs. non-TLS connections, then section
4.4
needs to emphasize that a single port number MUST be used in all
AVPs
of type DiameterIdentity. If the resolution of 273 requires use
of
the same port for TLS and non-TLS connections, then it would still be
a
good idea to include text in section 4.4 following the first
sentence cited
above that emphasizes that the same port number MUST
be used in all AVPs of
type DiameterIdentity even if a peer
connection request was received on a
different port.
If the URI prefix may either be aaa: or aaas: depending
on transport
security, then text should be added to section 6 stating that
when
matching URIs for routing purposes, the "s" in aaas: should
be
dropped before the compare is made.
Submitter
name: David Spence
Submitter email address:
DSpence@Interlinknetworks.com
Date first submitted: February 25,
2002
Reference:
Document: Base
Comment type: T
Priority:
S
Section: 4.1
Rationale/Explanation of issue:
The AVP Flag rules
tables in the various Diameter drafts specify in
which AVPs the 'M' bit MUST
be set, in which AVPs it MUST NOT be set,
etc.
However section 4.1 of
the base draft states:
A Diameter node that sets the 'M' bit in an AVP
that is not
defined in a given message's ABNF is at fault if the message
is
rejected.
In the next paragraph it states:
A Diameter node
that rejects a message due to an unrecognized AVP
with the 'M' bit set, and
the AVP in question is defined in the
message's ABNF, is at
fault.
These sentences make the criterion for setting the 'M' bit be
whether
or not the AVP is listed in the formal syntax for the message
in
which it appears. This is in direct contradiction to the criterion
that
the 'M' bit should be set according to the specification in the
AVP Flag
rules table of the draft defining the AVP.
Life gets complicated,
however, when an AVP defined in one Diameter
Application or a vendor-specific
AVP gets included in a message
defined in another Diameter Application. This
is allowed for most
Diameter messages because the "* [ AVP ]" construct
appears in most
message specifications.
So what happens if the sender
of the message considers such an AVP to
be critical to its intent, but the
recipient of the message does not
understand the AVP? The answer is that an
interoperability failure
happens. Some have argued (I have at times) that
Diameter's
open-ended extensibility is actually one of its
weaknesses.
At the AAA WG interim meeting in Santa Clara in May 2001,
the
extensibility-is-good faction reached a compromise with
the
interoperability-failures-are-bad faction that resulted in the
at
fault rules that appear in section 4.1 of the base draft. The
issue
here is that it is important to get the rules right.
Considering
that a Diameter node may include non-standard AVPs, and
considering that it
may be critical to the security or business
requirements of the parties
involved to know whether or not such AVPs
are accepted and processed, and
considering that interoperability
failures are not in the best interests of
any of the parties
involved, I propose the following principles to govern
setting of the
'M' bit:
1) AVP specifiers should be encouraged to
require setting the 'M'
bit of any AVP for which the interest of any of the
parties
would be hurt were the AVP to be ignored.
2) Implementors
should be required to provide alternatives to
sending non-standard AVPs with
the 'M' bit set. These may
include:
a) If a message is rejected
because it contains a non-standard
AVP with the 'M' bit set, the
implementation may resend the
message without the AVP, possibly inserting
additional
standard AVPs instead.
b) A configuration option may be
provided on a system wide, per
peer, or per realm basis that would
allow/prevent particular
non-standard, Mandatory AVPs to be sent. Thus
an
administrator could change the configuration to avoid
interoperability
problems.
3) An implementation that does not comply with the
above
requirements is not compliant with the Diameter
standard.
Examples
--------
Example 1: If I were to define a
vendor-specific
Interlink-Wowee-Zowee-Filter-Rule AVP, I would specify that
the 'M'
bit MUST be set (I certainly don't want the filters to be
ignored).
An implementation sending this AVP would be compliant if,
upon
receiving a rejection for a message containing the AVP, it
re-sent
the message with the NAS-Filter-Rule AVP in place of
the
Interlink-Wowee-Zowee-Filter-Rule AVP. Alternatively,
an
implementation could achieve compliance by offering a
per-realm
configuration option to control what realms to send
the
Interlink-Wowee-Zowee-Filter-Rule AVP to.
Example 2: NASCO NASes
always include the NAS-Filter-Rule AVP in
Accounting-Request messages on the
theory that inclusion of this AVP
in accounting records may be critical to
some providers' auditing
requirements. NASCO is permitted to do this because
the construct
"* [ AVP ]" appears in the formal syntax of the
Accounting-Request
message. The 'M' bit is set because the table in section
2.1 of the
NASREQ standard requires it. ACME Accounting Servers do
not
understand the NAS-Filter-Rule AVP. If they receive an
Accounting
Request message for a NASREQ session that includes
the
NAS-Filter-Rule AVP with the 'M' bit set, they reject the message.
Thus no accounting can ever happen between a NASCO NAS and an
ACME
Accounting Server. Who is at fault? ACME argues that according
to
Diameter-08, NASCO is at fault because neither of the tables in
section
10.2 of NASREQ list the NAS-Filter-Rule AVP.
Requested
change:
Replace the at fault rules in section 4.1 with the following
text.
(Note: the editor may decide to move this discussion to another,
more
appropriate section of the draft.)
The 'M' bit MUST be set
according to the rules defined for the AVP
containing it. In order to
preserve interoperability, a Diameter
implementation MUST be able to exclude
from a Diameter message any
Mandatory AVP which is neither defined in the
base Diameter
standard nor in any of the Diameter Application
specifications
governing the message in which it appears. It MAY do this in
one
of the following ways:
1) If a message is rejected because it
contains a Mandatory AVP
which is neither defined in the base Diameter
standard nor in
any of the Diameter Application specifications governing
the
message in which it appears, the implementation may resend the
message
without the AVP, possibly inserting additional standard
AVPs
instead.
2) A configuration option may be provided on a system wide,
per
peer, or per realm basis that would allow/prevent particular
Mandatory
AVPs to be sent. Thus an administrator could change
the configuration to
avoid interoperability problems.
Diameter implementations are required to
support all Mandatory
AVPs which are allowed by the message's formal syntax
and defined
either in the base Diameter standard or in one of the
Diameter
Application specifications governing the message.
Submitter name: Johan Johansson
Submitter email address:
johanj@ipunplugged.com
Date first submitted:
2002-02-26
Reference:
Document: base
Comment type: T
Priority:
1
Section: 10.1, 6.8
Rationale/Explanation of issue:
STR and
ASR messages do not belong to any specific application but
rather to all of
them. This means that they will take *any* route to
a realm even if it is a
dead end. They should contain
Auth-Application-Id avps.
Let the realm
R be a realm with (separate) home servers N and M for
NASREQ and MIP and
assume that from a given realm the normal route
passes through a node S that
has one NASREQ route to R that will
make messages enter R via N and one MIP
route that will make
messages enter R via M,
e.g.
S----------------X------------X------------N
|
+------------X------------M
Since
M and N have no common application they will not be peers.
Assume that
there is an active MIP session at M that the access
device determines to
terminate by sending an STR. There is nothing
that prevents S from routing
the STR down the N path.
Requested changes:
6.8: I haven't thought
of a good change to this section yet. But it
should state that messages
regarding a session for a particular
application should contain the id of
that application.
10.1:
Change
+-----------------------------------------------+
| Command-Code
|
|---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name
|CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
Acct-Application-Id
|0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0
|0 |0 |0 |0 |0 |0 |0
|
to
+-----------------------------------------------+
|
Command-Code |
|---+---+---+---+---+---+---+---+---+---+---+---+
Attribute
Name
|CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
Acct-Application-Id
|0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0
|0 |0 |0 |1 |0 |1 |0 |
I guess the RAR messages should probably also have
the
Auth-Application-Id for similar purposes but I'll leave that for
those
who actually use it to comment on.
j
Submitter name: Bob Kopacz
Submitter email address:
BKopacz@InterlinkNetworks.com
Date first submitted: 02-27-2002
Reference:
http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00314.html
Document:draft-mobileip-08
Comment type: Technical
Priority:1
Section:
Rationale/Explanation of issue:
Changes to generation &
handling of the Accounting-Multi-Session-Id AVP.
The following lines
prefixed with "*" are extracted from
draft-mobileip-08. The lines are
numbered to make them referencable
in the discussion.
*01 1.2
Inter-Realm Mobile IP
*02
*03 [...]
*04
*05 For new sessions, the
AAAH MUST create an accounting session
*06 identifier, which is added to the
Accounting-Multi-Session-Id AVP in
*07 the HAR message sent to the home
agent.
*08
*09 During the creation of the HAR, the AAAH MUST use a
different session
*10 identifier than the one used in the AMR/AMA (see figure
2). Of
*11 course, an AAAH MUST use the same session identifier for all
HARs
*12 initiated on behalf of a given mobile node's session.
[...]
*13
(1) According to the Introduction, an AAAH may be
session-stateless. I
don't think a session-stateless AAAH can differentiate a
new session
from a handoff of an existing session. Therefore a
session-stateless
AAAH couldn't send the same session-id for handoffs, as
stated in line *11.
*14 [...]
*15
*16 Upon receipt of the HAR, the
Home Agent first processes the Diameter
*17 message. [...] The
Accounting-Multi-Session-Id AVP in
*18 the HAR MUST be included in the HAA,
which is then forwarded to the
*19 AAAH.
*20
(2) The last sentence
is not quite right. While the HA does send an
Accounting-Multi-Session-Id AVP
in the HAA, it may be a different one
than was received in the HAR. (see
lines *44-*46).
*25 1.3 Support for Mobile IP Handoffs
*26
*27
[...]
*28
*29 Since the new AAAH in the home network MAY not have access
to the
*30 session identifier that was used by the old AAAH, it is necessary
for
*31 the resulting HAR received by the HA to be identified as a
*32
continuation of an existing session. If the HA receives an HAR for a
*33
mobile node, with a new session identifier, and the HA can guarantee
*34 that
this request is to extend service for an existing service, then
*35 the HA
MUST be able to modify its internal session state information
*36 to reflect
the new AAAH and session identifier. The HA MUST also
*37 issue an STR
message with the old session identifier to the AAAH it
*38 was communicating
with when using the old session identifier.
*39
*40 It is necessary for
accounting records to have some commonality
*41 across handoffs in order for
correlation to occur. Therefore, in the
*42 event that a home agent receives
an HAR with a different Accounting-
*43 Multi-Session-id AVP (and obviously a
different Session-Id AVP), the
*44 home agent MUST send an HAA with the
Accounting-Multi-Session-Id AVP
*45 that was received by the AAAH in the
first HAR for the mobile's
*46 session. This modified
Accounting-Multi-Session-Id AVP will be
*47 returned to the foreign agent by
the AAAH in the AMA. Both the
*48 foreign and home agents MUST include the
Accounting-Multi-Session-Id
*49 in the accounting messages.
*50
(3)
Since the AAAH must be prepared to have the
AAAH-generated
Accounting-Multi-Session-Id overridden by the HA, the protocol
should
change to just have the HA always specify
the
Accounting-Multi-Session-Id.
The thinking is that the HA is
constant over the MN's session, while the
AAAHs and AAAFs and FAs change. So
the HA is in a position to specify a
constant Accounting-Multi-Session-Id,
eliminating the extra
complications of a switcheroo.
The proposal is
that the AAAH will not send a
Accounting-Multi-Session-Id in the HAR. The HA
MUST send a
Accounting-Multi-Session-Id in the HAA. All of the messages for
a
MN's session will have the same value for
the
Accounting-Multi-Session-Id AVP.
(4) Since the AAAH may be
session-stateless, the HA would send the STR
to the AAAH, as indicated in
lines *36-*38, if and only if the AAAH
has changed.
Requested
change:
In Section 1.2 Inter-Realm Mobile IP
Replace:
"For
new sessions, the AAAH MUST create an accounting session
identifier, which is
added to the Accounting-Multi-Session-Id AVP in
the HAR message sent to the
home agent.
"During the creation of the HAR, the AAAH MUST use a
different session
identifier than the one used in the AMR/AMA (see figure 2).
Of
course, an AAAH MUST use the same session identifier for all
HARs
initiated on behalf of a given mobile node's session.
[...]
With:
"During the creation of the HAR, the AAAH MUST use a
different session
identifier than the one used in the AMR/AMA.
"If
the AAAH is session-stateful, it should send the same session
identifier for
all HARs initiated on behalf of a given mobile node's
session.
"If
the AAAH is not session-stateful, it will manufacture a unique
session-id for
every HAR. (Note--This will not cause a problem for
the HA, who must be able
to recognize a handoff even if the AAAH
thinks the session is new; an AAAH
may incorrectly view a session as
new when the handoff AMR goes to a
different AAAH than the previous
AMR).
- - - -
In Section 1.2
Inter-Realm Mobile IP
Replace the last sentence of the following
paragraph:
Upon receipt of the HAR, the Home Agent first processes the
Diameter
message. [...] The Accounting-Multi-Session-Id AVP in
the HAR
MUST be included in the HAA, which is then forwarded to
the
AAAH.
With:
The HA MUST include an
Accounting-Multi-Session-Id AVP in the HAA
returned to the AAAH.
- - -
-
In section 1.3 Support for Mobile IP
Handoffs
Replace:
Since the new AAAH in the home network MAY not
have access to the
session identifier that was used by the old AAAH, it is
necessary for
the resulting HAR received by the HA to be identified as
a
continuation of an existing session. If the HA receives an HAR for
a
mobile node, with a new session identifier, and the HA can
guarantee
that this request is to extend service for an existing service,
then
the HA MUST be able to modify its internal session state
information
to reflect the new AAAH and session identifier. The HA MUST
also
issue an STR message with the old session identifier to the AAAH
it
was communicating with when using the old session identifier.
It is
necessary for accounting records to have some commonality
across handoffs in
order for correlation to occur. Therefore, in the
event that a home agent
receives an HAR with a different Accounting-
Multi-Session-id AVP (and
obviously a different Session-Id AVP), the
home agent MUST send an HAA with
the Accounting-Multi-Session-Id AVP
that was received by the AAAH in the
first HAR for the mobile's
session. This modified Accounting-Multi-Session-Id
AVP will be
returned to the foreign agent by the AAAH in the AMA. Both
the
foreign and home agents MUST include the
Accounting-Multi-Session-Id
in the accounting
messages.
With:
"Since the new AAAH in the home network MAY not
have access to the
session identifier that was used by the old AAAH, or since
the AAAH
may be session-stateless, it is necessary for the resulting
HAR
received by the HA to be identified as a continuation of an
existing
session.
"If the HA receives an HAR for a mobile node, with
a new session
identifier, and the HA can guarantee that this request is to
extend
service for an existing service, then the HA MUST be able to
modify
its internal session state information to reflect the (possibly)
new
AAAH and new session identifier.
"If the AAAH is new, the HA MUST
also issue an STR message with the old
session identifier to the AAAH it was
communicating with when using
the old session identifier.
"It is
necessary for accounting records to have some commonality across
handoffs in
order for correlation to occur. Therefore, the home agent
MUST send the same
Accounting-Multi-Session-Id AVP value in all HAAs for
the mobile's session.
That is, the HA generates a unique
Accounting-Multi-Session-Id when receiving
an HAR for a new session, and
returns this same value in every HAA for the
session.
"This Accounting-Multi-Session-Id AVP will be returned to the
foreign
agent by the AAAH in the AMA. Both the foreign and home agents
MUST
include the Accounting-Multi-Session-Id in the accounting
messages."
- - - -
In Section 1.5 "Co-located Mobile
Node"
Add the following sentence:
"The HA includes the
Accounting-Multi-Session-Id AVP in the AMR sent to
the AAAH, as the AAAH may
find this a useful piece of session-state or
log entry information."
-
- - -
In section 2.3 Home-Agent-MIP-Request
Remove {
Accounting-Multi-Session-Id } from the message ABNF.
- - - -
In
section 2.4 Home-Agent-MIP-Answer
Change [ Accounting-Multi-Session-Id ]
to { Accounting-Multi-Session-Id }
in the message ABNF.
- - - -
In section 8.1 Mobile IP Command AVP Table,
Add an entry for the
Accounting-Multi-Session-Id AVP.
Attribute Name | AMR | AMA | HAR | HAA
|
------------------------------|-----+-----+-----+-----+
Accounting-Multi-Session-Id
| 0-1 | 1 | 0 | 1 |
- - - -
In section 8.2 Accounting AVP
Table
Add an entry for the Accounting-Multi-Session-Id AVP.
Attribute
Name | ACR | ACA
|
------------------------------|-----+-----+
Accounting-Multi-Session-Id
| 1 | 0-1 |
Submitter name: David Spence
Submitter email address:
DSpence@Interlinknetworks.com
Date first submitted: February 26,
2002
Reference:
Document: cms-sec
Comment type: E
Priority:
S
Section: many
Rationale/Explanation of issue:
Cms-sec-02 defined
an AVP called CMS-Cert.This AVP was removed in
cms-sec-03, however many
references to it remain.
Requested change:
Remove all references
to the CMS-Cert AVP.
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first
submitted: 02-27-2002
Reference:
Document: draft-mobileip-08
Comment
type:Technical
Priority: 1
Section:
Rationale/Explanation of
issue:
(1) It is difficult for the originating AAAF to correctly set
the
Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends
a
"real" HA IP address (not all zeroes or all ones). The AAAF only sees
an
IP address. The AAAF doesn't know just from the HA's IP address
whether that
represents an HA in the home network, or an HA in another
foreign network.
And maybe doesn't even know if the IP address is in
his own network.
The AAAF would have to call upon the DNS or other external
resources
to make this "home-agent-is-in-a-foreign-network" determination.
This
introduces unnecessary delay into the call setup by duplicating
work
which the AAAH has to do anyway upon receiving the AMR. That is,
when
the AAAH receives the AMR with a specified HA IP address, the AAAH
has
to map this IP address into the HA's realm and HA's
DiameterIdentity,
which will be used as the Destination-Realm and
Destination-Host of
the HAR. Furthermore, the AAAH may be able to make this
determination
more quickly than the AAAF, as a session-stateful AAAH may well
have
this information at hand as part of his session state.
(2) The
proposal here is to make the Home-Agent-In-Foreign-Network flag
one which is
not set by the originating-AAAF, but is instead set by
the AAAH. This
information will be returned to the originating-AAAF
and FA when the updated
feature vector is returned in the AMA.
(3) It may be that the originating
AAAF wants to disallow a foreign
HA, or allow a foreign HA but only if the
foreign HA is in the
originating AAAF's domain. If this capability is
desired, then two
new flags, settable by the originating AAAF, can be added
to
the
MIP-Feature-Vector:
Foreign-HA-Allowed-In-NonOriginating-Network
Foreign-HA-Allowed-In-Originating-Network
The
AAAH, after examining the home agent's IP address and determining
whether the
HA resides in the originating network, home network, or
some other foreign
network, can examine the two new flags to enforce
the originating AAAF's
policy on foreign HAs.
This way, the originating AAAF maintains the
ability to place retrictions
on foreign HAs before the call is
authorized.
(4) If (3) above is considered something an originating AAAF
wouldn't care
about, then these two new flags can be removed from the
proposal.
Requested change:
In section 1.2 Inter-Realm Mobile
IP
Replace:
If the Mobile Node was successfully authenticated, the
AAAH checks if
the Home Agent was located in the foreign realm, by checking
the
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.
If
the flag is enabled, then the Home Agent is located in the
foreign
realm then AAAH sends an HAR message to AAAF which contains a
MIP-
Reg-Request AVP.
With:
If the Mobile Node was successfully
authenticated, the AAAH checks if
the Home Agent is located in a foreign
realm. If so, the AAAH sets the
Home-Agent-In-Foreign-Network flag of the
MIP-Feature-Vector AVP.
Only the AAAH may set the
Home-Agent-In-Foreign-Network flag.
If the Home Agent is located in a
foreign realm other than the
originating realm, and
the
Foreign-HA-Allowed-In-NonOriginating-Network flag is zero, then
the
AAAH will return an AMA with a Result-Code
of
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
If the Home Agent is located
in the originating foreign realm, and
the
Foreign-HA-Allowed-In-Originating-Network flag is zero, then the
AAAH
will return an AMA with a Result-Code
of
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
Otherwise, if the Home Agent
is in a foreign network, and this is
allowed by both the originating AAAF and
the AAAH, then the AAAH sends
an HAR message to foreign HA which contains a
MIP-Reg-Request AVP.
- - -
In section 1.4 Allocation of Home Agent
in Foreign Network
Remove this paragraph:
In the event that the
mobile node requests a home agent in the
foreign network, and the AAAF
authorizes its use, the AAAF MUST set
the Home-Agent-In-Foreign-Network bit
in the MIP-Feature-Vector AVP.
This could happen when the AAA request is sent
to "extend" a mobile
node's current session.
- - -
In section
4.5 MIP-Feature-Vector AVP
Replace:
The MIP-Feature-Vector AVP
(AVP Code 337) is of type Unsigned32 and
is added with flag values set by the
Foreign Agent or by the AAAF
owned by the same administrative domain as the
Foreign Agent. The
Foreign Agent SHOULD include MIP-Feature-Vector AVP within
the AMR
message it sends to the AAAF.
With:
The
MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
conveys flag
values set by the Foreign Agent, the AAAF owned by the
same administrative
domain as the Foreign Agent, and the AAAH. The
flags in the
MIP-Feature-Vector are updated as the AMR makes it way to
the AAAH, and the
updated MIP-Feature-Vector is returned in the AMA.
The Foreign Agent
SHOULD include MIP-Feature-Vector AVP within the AMR
message it sends to the
AAAF.
- - -
In section 4.5 MIP-Feature-Vector AVP
To this
list of flags:
Flag values currently defined
include:
1Mobile-Node-Home-Address-Requested
2Home-Address-Allocatable-Only-in-Home-Realm
4Home-Agent-Requested
8Foreign-Home-Agent-Available
16
MN-HA-Key-Request
32 MN-FA-Key-Request
64 FA-HA-Key-Request
128
Home-Agent-In-Foreign-Network
256
Co-Located-Mobile-Node
Add:
512Foreign-HA-Allowed-In-NonOriginating-Network
1024
Foreign-HA-Allowed-In-Originating-Network
- - -
In section 4.5
MIP-Feature-Vector AVP
Replace:
If the mobile node requests a home
agent in the foreign network
either by setting the home address field to all
ones, or by
specifying a home agent in the foreign network, and the
AAAF
authorizes the request, the AAAF MUST set the
Home-Agent-In-Foreign-
Network bit to one.
The Foreign Agent MUST NOT
set the Foreign-Home-Agent-Available, and
Home-Agent-In-Foreign-Network flag
to one.
When the AAAF receives the AMR message, it MUST first verify that
the
sender was an authorized Foreign Agent. The AAAF then takes
any
actions indicated by the settings of the MIP-Feature-Vector AVP
flags.
The AAAF then MAY set additional flags.Only the AAAF may set
the
Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network
flags to one.
This is done according to local administrative policy.
When the AAAF has
finished setting additional flags according to its
local policy, then the
AAAF transmits the AMR with the possibly
modified MIP-Feature-Vector AVP to
the AAAH.
With:
If the mobile node requests a home agent in the
foreign network either
by setting the home address field to all ones, or by
specifying a home
agent in the foreign network, and the AAAF authorizes the
request, the
AAAF may restrict the HA to certain networks by setting
the
Foreign-HA-Allowed-In-NonOriginating-Network and/or
the
Foreign-HA-Allowed-In-Originating-Network flag.
The Foreign Agent
MUST NOT set the Foreign-Home-Agent-Available to one
and the
Foreign-HA-Allowed-In-Originating-Network flag to zero.
When the AAAF
receives the AMR message, it MUST first verify that the
sender was an
authorized Foreign Agent. The AAAF then takes any
actions indicated by the
settings of the MIP-Feature-Vector AVP flags.
The AAAF then MAY set
additional flags. Only the AAAF may set the
Foreign-Home-Agent-Available,
Foreign-HA-Allowed-In-Originating-
Network, and
Foreign-HA-Allowed-In-NonOriginating-Network flags to
one. This is done
according to local administrative policy. When the
AAAF has finished setting
additional flags according to its local
policy, then the AAAF transmits the
AMR with the possibly modified
MIP-Feature-Vector AVP to the AAAH.
Submitter name: David Spence
Submitter email
address: DSpence@Interlinknetworks.com
Date first submitted: March 1,
2002
Reference:
Document: NASREQ
Comment type: T
Priority:
1
Section: various
Rationale/Explanation of issue:
Although
nasreq-08 is not entirely consistent on this, it seems to require
the
Service-Type AVP to appear in all messages.Unfortunately, RADIUS does
not
make this requirement.Therefore I am relaxing the requirement in
nasreq from
MUST to SHOULD.The alternative would be to add an heuristic to
the
RADIUS/Diameter gateway section explaining how a RADIUS to Diameter
gateway
should infer the value of the Service-Type based on the attributes
present in
the RADIUS message.Being lazy, I opt for relaxing
the
requirement.
Requested change:
State that Service-Type
SHOULD (rather than MUST) be included, change the
ABNF from "{ Service-Type
}" to "[ Service-Type ]", and change the AVP
Ocurrence Tables from 1 to
0-1.
Submitter: Jesse Walker
Submitter email address:
jesse.walker@intel.com
Date first submitted: March 2, 2002
Reference:
http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt
Document:
NASREQ, EAP
Comment type: T
Priority: S
Section:
2.1
Rationale/Explanation of issue:
Diameter keying AVPs cannot
securely distribute a key for its intended
purpose. While they may be
suitable for handing off a key between the
authentication server and the
NAS/Access Point, intended for
communications between themselves alone, as
constituted today they are
insecure for transferring a session key intended
for use between the
NAS/AP and the client. To become secure, the key handoff
has to be
enhanced to incorporate additional cryptographic state that can
be
used to provide assurances to all these parties involved in
the
transaction.
Examples of such state are the information
communicated among the KDC and
the communicating parties in the
Needham-Schroeder and Otway-Rees
protocols.
>Given that the AS and
AP trust each other (assumed), why
>is a reasonable cryptographic protocol
(such as CMS or even IPSec) is
>insufficient to protect the transfer of a
STA-AP session key from the AS to
>the AP?
There has been in fact
ample discussion around exactly these points. There
is, for instance, the
whole key handoff discussion, of which AS-AP handoff
is a special case. As a
second example, there is the flap around the
Arbaugh-Mishra 802.1X paper,
which echos many of our key handoff
discussions, and which we have also
discussed.
But even if we had never discussed these points before, we
would be forced
to if the issue were raised; if someone perceives holes in
our security,
then these have to be addressed, and making an appeal that this
wasn't ever
an issue before doesn't help.
I don't buy the assumed
trust argument, because it is not specific enough to
offer any useful
insight. Let me respond to it by asking why should we
assume the AS and the
AP trust each other, and, more to the point, for what
purpose should they
trust each other? I think the correct assumptions are
something
like
a. The AS and the AP share a key used for key distribution, and that
both
parties can be trusted to use this key for no other purpose, and to
expose
it to no other parties;
b. The AS can be trusted to distribute
a fresh key whenever it distributes a
key.
Why should we assume
substantially more about the AP-AS relationship? Each
assumption represents a
new point of attack if compromised, so we would do
well to think about
eliminating as many assumptions as possible.
Protocols exist that would
allow us to reduce the number of assumptions we
make by incorporating
explicit verification in place of trust assumptions.
It is feasible to add
protocol state allowing the AS to verify that the key
distribution request
really did originate with a legitimate station and not
as the result of a
rogue AP or a rogue station. It is feasible for both the
AS and the station
to verify that the key distribution is live, even though
they can't verify it
is fresh (that's why we have to make the second trust
assumption). It is
feasible for both the AP and the station to verify that
the AS intended to
distribute this particular key to this particular <AP,
station> pair,
i.e., that each is talking to the other intended recipient of
the key, and to
no one else, and for the protocol to protect against either
the AP or the
station cheating (except by exposing a key). The existing
method of throwing
keys over the fence to the AP does not have any of these
guarantees built in,
so we have to assume much more to use it. Each such
assumption may reasonable
in a sufficiently constrained environment, but I
question whether together
they are reasonable in a network as open as a
WLAN.
And I don't buy
basing the security on mechanisms like IPsec. By definition,
IPsec provides
bilateral security between the two parties sharing a security
association,
and binds only the two together. A key distribution protocol of
the sort we
are discussing is not a bilateral relationship. Key distribution
is a
trilateral relationship among three parties--the AS, the AP, and
the
station--and because of this will have to cryptographically bind the
three
parties together somehow to be secure, i.e., to minimize points to
attack.
You can replace IPsec by any other bilateral security protocol, and
the same
argument obtains.
My position is that it would be prudent for
us to look at adapting a key
distribution protocol that reduces our exposure
by minimizing security
assumptions. I believe this because we are building
systems that expose many
more attack points than in the past. Indeed, I think
the burden of proof is
on the other foot: what leads us to think the special
conditions and
circumstances and topologies that permitted security shortcuts
in the past
are still applicable in the more fragile environments we are
building today?
Why should the mechanisms that worked in more restricted
environments still
be applicable unchanged when moved into new environments
that, on the
surface at least, seem to violate many of the assumptions we
made before?
Proposed change:
A three-way handshake should be
incorporated so that key distribution and
confirmation can be dealt with
uniformly across multiple environments.
These key distribution methods
require active participation by three
parties instead of two.
of binding is described in
Issue 399. This involves one NAS
impersonating another. If the Route-Record AVP isn't checked
carefully by each Diameter agent along the path, by the time
the Request reaches the Diameter Server, it will be unable
to verify the Origin-Host AVP. As a result, it may send keys
to the wrong NAS.
To fix this it is necessary to bind the key to the NAS and
client for which it is to be used, so that the impersonated
NAS can detect a mismatch. It is also necessary for some
"liveness" to be incorporated into the package so that keys
cannot be replayed.
Submitter name: David Spence
Submitter email address:
DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: NASREQ-09
Comment type: T
Priority:
S
Section: various
Rationale/Explanation of issue:
There are a
number of attributes defined in RADIUS RFCs that are
needed for the correct
operation of the Diameter NASREQ application.
They are:
CODE NAME
RFC
--------- ------------------ ----
29 Termination-Action 2865
41
Acct-Delay-Time 2866
51 Acct-Link-Count 2866
55 Event-Timestamp 2869
78
Configuration-Token 2869
85 Acct-Interim-Interval 2869
87 NAS-Port-Id
2869
88 Framed-Pool 2869
95 NAS-IPv6-Address 3162
98 Login-IPv6-Host
3162
Note: These AVPs were not added to nasreq-09, so this issue
requires
more work in nasreq.
Requested change:
Add these
attributes to nasreq as Diameter AVPs.
Submitter name: David Spence
Submitter email address:
DSpence@Interlinknetworks.com
Date first submitted: March 4,
2002
Reference:
Document: MobileIPv4
Comment type: T
Priority:
2
Section:
Rationale/Explanation of issue:
The following attribute
is defined in RADIUS for use in accounting
messages.It might be useful in the
MobileIPv4 application.
CODE NAME RFC
--------- ------------------
----
55 Event-Timestamp 2869
Requested change:
Consider adding
this attribute to MobileIPv4 as a Diameter AVP.
Note: This AVP will need
to be defined in NASREQ for RADIUS
compatibility. See issue TBA.
Submitter name: David Spence
Submitter email
address: DSpence@Interlinknetworks.com
Date first submitted: March 4,
2002
Reference:
Document: NASREQ
Comment type: T
Priority:
S
Section:
Rationale/Explanation of issue:
The RADIUS
Acct-Terminate-Cause attribute (#49) is superseded in
Diameter by the
Termination-Cause AVP (#295).However, there are
many values defined for
Acct-Terminate-Cause that have no counterpart
in Termination-Cause.Many of
these values are nasreq-specific.
Requested change:
Define
addional values in nasreq for the base draft's
Termination-Cause AVP to
cover the semantics of the RADIUS
Acct-Terminate-Cause attribute.Ensure that
all values
for Acct-Terminate-Cause listed in IANA's radius-types.txt
are
covered.Specify the mapping between the Acct-Terminate-Cause
values
and the Termination-Cause values so that a RADIUS/Diameter
gateway can
translate between them.
Submitter name: Bob Kopacz
Submitter email
address:bkopacz@interlinknetworks.com
Date first submitted: 03-04-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Minor editing corrections.
Requested change:
The NASREQ
draft has a section "Legacy RADIUS Attributes" with text
along the lines of
"The Diameter protocol reserves the AVP Codes 0-255
for "legacy RADIUS"
support.The following table contains the RADIUS
attributes supported by this
Diameter application, their AVP code
values, types, possible flag values and
whether the AVP MAY be
encrypted. RADIUS attributes not listed are not
supported by the
Diameter protocol."
After section 4.0 Mandatory AVPs,
create a similar section 4.1 which
says something like the following (to
indicate the subset of RADIUS
attributes a Diameter Mobile-IP client/server
requires in its
dictionary):
> 4.1 Supported Legacy RADIUS
Attributes
>
> The Diameter protocol reserves the AVP Codes 0-255
for "legacy RADIUS"
> support.The base protocol defines the RADIUS
attributes User-Name,
> Session-Timeout, Acct-Session-Time,
Acct-Multi-Session-Id, Proxy-State,
> and Class, all supported by this
Diameter application.This application
> supports these RADIUS attributes
and no others.
- - -
In section 4.3MIP-Mobile-Node-Address
AVP
> The Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress
and
^^^^^^^^^^^^^^^^^^^
Change to "MIP-Mobile-Node-Address"
- -
-
In section 4.4MIP-Home-Agent-Address AVP
> The
Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress
and
^^^^^^^^^^^^^^^^^
Change to "MIP-Home-Agent-Address"
- -
-
In section 4.5MIP-Feature-Vector AVP
> Whenever the Foreign
Agent sets either the Mobile-Node-Home-Address-
> Requested flag or the
Home-Agent-Request flag to one, it MUST set the
^^^^^^^^^^^^^^^^^^
Change
to "Home-Agent-Requested"
- - -
In the following, move the 5.5.1
section header down by one paragraph,
i.e.
Change:
>
5.5Distributing the Foreign-Home Session Key
>
> 5.5.1 Home Agent
in the home network
>
> If the home agent is in the home realm,
then the AAAH has to generate
> the Foreign-Home session key. Otherwise,
it is generated by the AAAF.
>
> In the cases when the AAAH
generates the Foreign-Home session key,
> ...
To:
>
5.5Distributing the Foreign-Home Session Key
>
> If the home agent
is in the home realm, then the AAAH has to generate
> the Foreign-Home
session key. Otherwise, it is generated by the AAAF.
>
> 5.5.1 Home
Agent in the home network
>
> In the cases when the AAAH generates
the Foreign-Home session key,
> ...
- - -
In section
6.6MIP-MN-to-HA-Key AVP
> * [ AVP ].fi
Remove ".fi"
- -
-
In section 11.1Normative References
> [DIAMBASE]P. Calhoun,
H. Akhtar, J. Arkko, E. Guttman, A. Rubens,
> "Diameter Base Protocol",
draft-ietf-aaa-diameter-08.txt,
> IETF work in progress, November
2001.
Change to draft-10 (or maybe draft-11 for the next
revision)
> [MOBILEIP] C. Perkins, Editor. IP Mobility Support.
>RFC 2002, October 1996.
RFC2002 has been obsoleted by RFC3220,
January 2002.
> [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter
CMS Security
> Application",
draft-ietf-aaa-diameter-cms-sec-03.txt,
> IETF work in progress, November
2001.
Change to draft-ietf-aaa-diameter-cms-04.txt (or maybe -05 for next
revision)
> [MIPKEYS]C. Perkins, P. Calhoun, "AAA Registration
Keys for Mobile
>IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work
in
>progress, July 2001.
The above has expired, but key-09, 26
February 2002, is out.
Submitter name: Bob Kopacz
Submitter email
address:bkopacz@interlinknetworks.com
Date first submitted: 03-04-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
I
may be missing something significant here, but ...
This issue has to do
with how an AAAF and AAAH, when given a Home
Agent's IP address, derive the
domain/realm/DiameterIdentity
information needed by the Diameter AAA
servers.
This issue may also have some bearing on the relationship
between a
DiameterIdentity and a FQDN.
Unfortunately I don't have a
good solution to present, so I'm
indicating what the problems are, as
indicated by "-->".It may
be that the solution is to enhance the Mobile IP
protocol to
provide more information in the Registration Request.
THE
AAAF's PROBLEM:
------------------
Section 1.4. Allocation of Home Agent
in Foreign Network, says
the following:
> 1.4Allocation of Home
Agent in Foreign Network
>
> [...]
>
> In the event
that the mobile node requests a home agent in the
> foreign network, and
the AAAF authorizes its use, the AAAF MUST set
> the
Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
> This
could happen when the AAA request is sent to "extend" a mobile
> node's
current session.
>
-->(1) I think some text needs to be added
to describe how the AAAF
determines if the HA is in a foreign
network.
That is, I am guessing the method is along these lines:
Suppose a MN initially connects, is allocated an HA, and
later
undergoes a handoff to a new FA and new AAAF.Depending on the
MN's
new point of attachment, the new FA and AAAF may or may not be in
the
same foreign domain as before, or the foreign domain may
be same but the
AAAFs are different, or the handoff may involve
the same AAAF as
before.
In the AMR, the new AAAF is provided with the MN user's NAI and
the
HA's IP address.Say the MN user is "bob@donut.com" and the
specified
HA IP address is 1.2.3.4.
The new AAAF does a reverse DNS
lookup of tbe HA's IP address,
1.2.3.4, and the DNS response is that IP
address 1.2.3.4 corresponds
to an FQDN of
"homeagent86.westcoast.spinach.com".
Now the AAAF extracts the realm part
of the NAI, "donut.com", and
pre-pends a dot, coming up with ".donut.com".The
AAAF then checks
if this ".donut.com" string is a trailing substring of
the
"homeagent86.westcoast.spinach.com" FQDN.It isn't, so the
AAAF
concludes the HA is in a foreign network and sends
the
Home-Agent-In-Foreign-Network flag with a value of one.If the tail
of
the FQDN matched ".donut.com", the AAAF would conclude the HA was
in the home
network.
-->(2) This may or may not be anywhere close to the AAAF's
method.
At any rate, the method should be described in sufficient detail
for an AAAF implementation.
-->(3) If this DNS reverse lookup is
indeed the AAAF's method to
make this "home-agent-is-in-a-foreign-network"
determination, then
this introduces a delay into the handoff, and should
probably be
noted.
THE AAAH's
PROBLEM
------------------
Section 1.2 Inter-Realm Mobile IP, says the
following:
>
> 1.2Inter-Realm Mobile IP
>
>
[...]
>
> If the Mobile Node was successfully authenticated, the
AAAH checks if
> the Home Agent was located in the foreign realm, by
checking the
> Home-Agent-In-Foreign-Network flag of the
MIP-Feature-Vector AVP.If
> the flag is enabled, then the Home Agent is
located in the foreign
> realm then AAAH sends an HAR message to AAAF
which contains a MIP-
> Reg-Request AVP.
Continuing the example,
suppose the AAAF has determined that the
HA is in a foreign network, and has
forwarded the AMR to the home
realm.The AAAH receives the AMR, and the AMR
indicates the HA's
address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag
is ON,
and the User-Name is "bob@donut.com".
-->(4) Now the AAAH
wants to send an HAR to the HA.But Diameter
routes by Destination-Realm and
Destination-Host, not by IP address,
so the AAAH has to somehow come up with
the HA's DiameterIdentity
for the Destination-Host AVP of the HAR, and the
HA's realm for the
Destination-Realm of the HAR.
AAAH's 1st Problem:
How to discover the HA's DiameterIdentity:
If the AAAH maintains
session-state, then this HA identity
information can be part of the cached
session-state information,
and there may be no problem.But there is a problem
if either
(a) the AAAH is not session-stateful, or (b) the AAAH
is
session-stateful but has no session-state info because the handoff
AMR
is received by a different AAAH than the AAAH which received
the original AMR
for the session.
So if we have case (a) or (b), the hapless AAAH is
holding the HA's
IP address, and needs to come up with the HA's realm
and
DiameterIdentity.The method might be along these lines:
The AAAH
can do a reverse lookup of the IP address 1.2.3.4, and
again DNS returns an
FQDN of "homeagent86.westcoast.spinach.com"
*If* the DiameterIdentity is
the same as the FQDN, then the AAAH
constructs the HAR's Destination-Host =
"homeagent86.westcoast.spinach.com". (An aside: I haven't kept up
with
the recent DiameterIdentity thread, but I thought the
DiameterIdentity needed
to be something like "FQDN+extra", so that
multiple Diameter applications
could run on the same box.In
which case the FQDN isn't
sufficient).
AAAH's 2nd Problem: How to discover the HA's
Realm:
The AAAH still needs to derive the HAR's Destination-Realm,
from
the FQDN.The realm is probably either "westcoast.spinach.com"
or
"spinach.com".Does the AAAH have a way to know for sure, or
is the best-guess
algorithm to say that the realm is what
follows the next-to-last dot of the
FQDN, e.g. "spinach.com".
-->(5) Again, this may or may not be
anywhere close to what the
AAAH needs to do to surmise the HA's realm and
identity.At any
rate, the method should be described in sufficient detail
to
implement an AAAH.
-->(6) If this DNS reverse lookup is indeed
part of the AAAH's
method, then this introduces a delay (maybe a 2nd delay
depending on
what the AAAF had to do) into the handoff, and should probably
be
noted.
-->(7) It seems the AAAF and AAAH are both starting from
scratch
with the HA's IP address, and duplicating efforts and delays.
Maybe
the AAAF's DNS-lookup results (or whatever useful knowledge the
AAAF
possesses) could be passed along to the AAAH.
Submitter:
Bernard Aboba
Submitter email address: aboba@internaut.com
Date first
submitted: March 5, 2002
Reference:
Document: EAP-00
Comment type:
T
Priority: S
Section: 4.0
Rationale/Explanation of
issue:
Diameter EAP has some corner conditions that have turned out to be
a big
headache. These include:
a. Role reversal. In EAP it is possible for the peer to attempt to
authenticate the NAS.
b. Conflicting messages. These occur when the encapsulated
EAP Message does not agree with the Diameter message within
which it is encapsulated.
c. Use of reply message instead of Notification Request. This results
in the NAS having to do translation, Identifier inseration, and more.
NASREQ needs to make clear, as
RFC 2865 does, that a NAS makes its
access decision based on the Diameter
message alone (Accept or Reject),
*not* based on the contents of any
enclosed attributes, including an
EAP-Message attribute. This makes sense,
since the NAS acts as a
"passthrough" for EAP.
However, this makes
for some interesting corner conditions, because
the following packets may be
sent by the Diameter server:
a. Accept/EAP-Message/EAP-Failure
b.
Reject/EAP-Message/EAP-Success
c. Accept/EAP-Message/Notification
d.
Reject/EAP-Message/Notification
e. Accept (no EAP Message)
f. Reject (no
EAP Message)
g. Accept/EAP-Message/EAP-Failure, Reply-Message
h.
Accept/EAP-Message/EAP-Success, Reply-Message
i.
Reject/EAP-Message/EAP-Failure, Reply-Message
j.
Accept/EAP-Message/EAP-Success, Reply-Message
k.
Challenge/EAP-Message/EAP-Success
l.
Challenge/EAP-Message/EAP-Failure
There are probably more corner
conditions than this, but my fingers are
getting tired :(
a. Message a
is a problem because the Accept says "grant access" while the
Failure, if
passed on to the EAP peer will make it think that
authentication has failed.
If there are alternate indications of
success, one might argue that the peer
will eventually figure it
out. For media in which there are no such
indications (IEEE 802 and 802.11
are examples), a timeout will result.
b. Message b is a problem because the Reject says "no access" while
the
EAP-Success passed to the peer makes it think it is successful.
If
there are alternate indications of Failure on a given media, the peer
may
eventually figure things out. On IEEE 802.11 a Disassociate from the
AP would
put things right, as would an LCP-Terminate in PPP. On wired IEEE
802 there
is no alternate indication of failure, so a timeout will result.
c-d.
These are an issue since the peer receives a displayable
Notification, but no
indication of Success/Failure. Alternate indications
might help, but for
media in which they don't exist, a timeout will
result.
e-f. Ditto,
except no notification.
g-j. These are a problem since it is not clear
within Diameter EAP how a
Reply-Message is to be handled within an EAP
conversation. Some NAS
implementations translate Reply-Message to an
EAP-Notification, resulting
in the NAS having*two* EAP messages to send to
the peer. Some NAS
implementations treat the Reply-Message as a terminal
non-ACK'd message,
in which case the subsequent EAP-Message attributes are
never sent. Which
interpretation is correct?
If you're in the
"translate to Notification" camp, then presumably the
Notification has to be
sent first, since the Success/Failure message
terminates the conversation and
therefore nothing can be sent after
that. Note that the Reply-Message doesn't
come with an Identifier field,
so presumably the NAS has to make one up. But
since the Success/Failure
already has an Identifier field in it, what is the
NAS/AP
supposed to do, particularly if the Identifier field is
incremented
sequentially? The problems are obviously worse if the
Reply-Message is
sent in the middle of the conversation, so that a simple
Identifier swap
wouldn't work.
k-l. These are problematic because an
Access-Challenge indicates a
continuing conversation, but an
EAP-Success/EAP-Failure is a terminating
message. Therefore the Diameter
Server will not receive a response to
these messages -- but the NAS will
neither have granted nor rejected
access.
Proposed change: Insert a
Diameter version of the RFC2869bis text:
2.6.1. Role reversal
Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction. Both peers may
act as authenticators and authenticatees at the same time.
However, role reversal is not supported by this specification. A Diameter
server MUST respond to a Access-Request encapsulating an EAP-Reques
with an Access-Reject. In order to avoid retransmissions by the peer,
the Access-Reject MAY include an EAP-Response/Nak packet indicating no
preferred method, encapsulated within EAP-Message attribute(s).
2.6.2. Conflicting messages
Access-Accept packets SHOULD have only ONE EAP-Message attribute in
them, containing EAP Success; similarly, Access-Reject packets SHOULD
only have ONE EAP-Message attribute in them, containing EAP Failure.
Where the authentication result implied by the encapsulated EAP packet
does not match the result implies by the Diameter Packet Type, the
authenticator MUST make its access control decision based on the Diameter
Packet Type (Access-Accept/Access-Reject), and not based on the contents
of the EAP packet encapsulated in one or more EAP-Message attributes, if
present.
Where the encapsulated EAP packet does not match the result implied by
the Diameter Packet Type, the combination is likely to cause confusion,
because the NAS and peer will arrive at different conclusions as to the
outcome of the authentication.
For example, an EAP Failure packet may be encapsulated within an Access-
Accept and an EAP Success packet may be encapsulated within an Access-
Reject. Alternatively, an EAP-Message attribute may not be included
within a Diameter Access-Accept or Access-Reject.
If the NAS receives an Access-Reject with an encapsulated EAP Success,
it will not grant access to the peer. However, on receiving the EAP
Success, the peer will be lead to believe that it authenticated
successfully.
If the NAS receives an Access-Accept with an encapsulated EAP Failure,
it will grant access to the peer. However, on receiving an EAP Failure,
the peer will be lead to believe that it failed authentication. If no
EAP-Message attribute is included within an Access-Accept or Access-
Reject, then the peer may not be informed as to the outcome of the
authentication, while the NAS will take action to allow or deny access.
As described in [RFC2284], the EAP Success and Failure packets are not
acknowledged, and these packets terminate the EAP conversation. As a
result, if these packets are encapsulated within an Access-Challenge, no
response will be received, and therefore the NAS will send no further
Access-Requests to the Diameter server. As a result, the NAS will not be
given an indication of whether to allow or deny access while the peer
will be informed as to the outcome of the authentication.
To avoid these conflicts, the following combinations SHOULD NOT be sent
by a Diameter server:
Access-Accept/EAP-Message/EAP Failure
Access-Accept/no EAP-Message attribute
Access-Reject/EAP-Message/EAP Success
Access-Reject/no EAP-Message attribute
Access-Challenge/EAP-Message/EAP Success
Access-Challenge/EAP-Message/EAP Failure
Access-Challenge/no EAP-Message attribute
Since the responsibility for avoiding these conflicts lies with the
Diameter server, the NAS MUST NOT "manufacture" EAP packets in order to
correct contradictory messages that it receives. This behavior,
originally mandated within [IEEE8021X], is likely to be deprecated.
2.6.3. Priority
In addition to containing EAP-Message attributes, Diameter messages may
also contain other attributes. In order to ensure the correct processing
of Diameter messages, on receiving an Access-Accept, Access-Reject or
Access-Challenge, the NAS SHOULD process other attributes first, then
decapsulate EAP-Message attribute(s), reconstitute the EAP packet and
send it to the peer.
2.6.4. Displayable messages
The Reply-Message attribute, defined in [RFC2865], Section 5.18,
indicates text which may be displayed to the user. This is similar in
concept to EAP Notification, defined in [RFC2284]. When sending a
displayable message to a NAS during an EAP conversation, the Diameter
server MUST encapsulate displayable messages within EAP-Message/EAP-
Request/Notification attribute(s). Reply-Message attribute(s) MUST NOT
be included in any Diameter message containing an EAP-Message attribute.
An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an
Access-Accept or Access-Reject packet.
In some existing implementations, a NAS receiving Reply-Message
attribute(s) copies the Text field(s) into the Type-Data field of an
EAP-Request/Notification packet, fills in the Identifier field, and
sends this to the peer. However, several issues arise from this:
[1] Unexpected Responses. On receiving an EAP-Request/Notification, the
peer will send an EAP-Response/Notification, and the NAS will pass
this on to the Diameter server, encapsulated within EAP-Message
attribute(s). However, the Diameter server may not be expecting an
Access-Request containing an EAP-Message/EAP-Response/Notification
attribute.
For example, consider what happens when a Reply-Message is included
within an Access-Accept or Access-Reject packet with no EAP-Message
attribute(s) present. If the value of the Reply-Message attribute
is copied into the Type-Data of an EAP-Request/Notification and
sent to the peer, this will result in an Access-Request containing
an EAP-Message/EAP-Response/Notification attribute being sent by
the NAS to the Diameter server. Since an Access-Accept or Access-
Reject packet terminates the Diameter conversation, such an Access-
Request would not be expected, and could be interpreted as the
start of another conversation.
[2] Identifier conflicts. While the EAP-Request/Notification is an EAP
packet containing an Identifier field, the Reply-Message attribute
does not contain an Identifier field. As a result, a NAS receiving
a Reply-Message attribute and wishing to translate this to an EAP-
Request/Notification will need to choose an Identifier value. It is
possible that the chosen Identifier value will conflict with a
value chosen by the Diameter server for another packet within the EAP
conversation, potentially causing confusion between a new packet
and a retransmission.
In order to avoid these problems, a NAS in pass-through mode receiving a
Reply-Message attribute from the Diameter server SHOULD silently discard
the attribute."