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
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