Issue #270
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
--------------------------------------------------------------------------------
Assigned #271
Submitter: Jari Arkko
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
--------------------------------------------------------------------------
(Revised)
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.
--------------------------------------------------------------------------
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 #272
Description of issue: Separation of the prepaid and postpaid accounting sessions
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.
--------------------------------------------------------------------------
Issue #273
From: David Frascone
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
--------------------------------------------------------------------------
Issue #274
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
--------------------------------------------------------------------------
Issue #275
Issue : Changes to state machine for ASR/ASA messages
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.
--------------------------------------------------------------------------
Issue #276
Issue : Remove section 1.6 from the CMS appl
Submitter name: Tony
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.
--------------------------------------------------------------------------
Issue #277
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+ |
--------------------------------------------------------------------------
Issue #278
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.
--------------------------------------------------------------------------
Issue #279
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."
--------------------------------------------------------------------------
Issue #280
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
--------------------------------------------------------------------------
Issue #281
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.
--------------------------------------------------------------------------
Issue #282
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.
--------------------------------------------------------------------------
Issue #283
Description of issue: Usage of TLS vs. IPsec
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
--------------------------------------------------------------------------
Issue #273
Description of issue: DNS SRV text needs to be updated
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
--------------------------------------------------------------------------
Issue #284
Issue : Possible modification to the Diameter Cost Control Application protocol
Submitter name: Paco Marin
Submitter email address: fmaring@airtel.es
Date first submitted: 02-18-2002
Reference:
Document: draft-hakala-diameter-credit-control-01.txt
Comment type: Technical
Hi all,
I've been taking look to the last version of the draft 'Diameter Credit Control Application'
(draft-hakala-diameter-credit-control-01.txt). I've been thinking about common services an operator
like my company needs to offer and the possibility of applying DIAMETER CCA to the charging part.
Sorry if some of the following issues are obvious, but I think despite of the most of the scenarios
being covered with the described protocol, however I did'nt find the way to use this protocol to
cover two possible scenarios. The referred scenarios are the following:
1.- Check of balance.
Sometimes is necessary to check if there is enough balance to grant a service to a subscriber.
Imagine a subscriber of a mobile comunications operator wants to download a melody or a 'logo' from
the Internet on his mobile phone (using the Short Message Service of GSM). In this scenario, there
are three parts: the subscriber, the network operator and a third party which is the service
provider. The third party will charge the sent melody (or logo) to the network operator just when
the network operator receives it, so it could be interesting to acknowledge the Short Message
delivery from the third party only when the subscriber has enough credit. This way the operator
avoids to pay for a message that will never be delivered because the final user (the subscriber) has
no credit enough. I've been thinking about the possibility of using 'session based credit control'.
However is hardly ineficient, the SM must be acknowledged immediately and the short message could
wait several days to be delivered to the final user (the user could be out of coverage), it implies
to keep the session opened until the SM is finally delivered.
2.- Increment of Credit
In some scenarios could be useful to add to the protocol the posibility to increase the balance
instead of decrementing it. As an example, could be a way to motivate the user access to
advertisement information in the internet or to receive adversiting Short Messages from a third
party. In these scenarios could be interesting to be able to increment the credit directly from the
client, as an example increase money on the user account or allow 1 free short message every 5
advertisement Short Message received.
I think there is no way to make it with the current version of the draft (please, please, please
correct me if I am wrong or confused).
The solution to these two scenarios should not be fundamental for the overall working of the
Diameter CCA, however it would apply flexibility enough to ease the use of the protocol to the
legacy architectures of the current network operators.
In my humble opinion a possible solution for both scenarios should be to include a new AVP.
PROPOSAL OF SOLUTION
A new AVP to indicate an operation on the balance is going to be accomplished could be added to the
proposed AVPs of the Diameter CCA protocol. This AVP could indicate if the action to be carried out
is a decrement, check of balance or an increment. If this new AVP is not included in the request,
the server should consider that the value of this one is '0', it will mean the behaviour of the
protocol will be the one described up to now. The new AVP could be:
'Balance-Management-Indicator', it should be of tipe Unsigned32 and its values could be:
'0': Decrement, the request and answer work as up to now. The 'Requested-Service-Unit' AVP
contains the unit to decrement, the 'Granted-Service-Unit' AVP contains the service units granted.
This units will be decremented in that moment from the user account.
'1':Check of balance, the 'Requested-Service-Unit' AVP could contains the service unit to check
if it is allowed to be carried out, the 'Granted-Service-Unit' AVP contains the service units
allowed to be carried out. This units will NOT be decremented from the user account.
'2': Increment, the request and answer work in a similar way as described for the value '0'.
The 'Requested-Service-Unit' AVP contains the unit to increment, the 'Granted-Service-Unit' AVP
contains the service units incremented. This units will be incremented in that moment in the user
account.
The accounted AVP table should be modified as follows:
+----------+
| Command |
| code |
+----+-----+
Attribute Name |ACR | ACA |
------------------------------+----+-----+
Balance-Management-Indicator |0-1 | 0 |
------------------------------+----+-----+
Maybe I'm confused..... correct me in that case.
Thanks a lot.
Paco.
--------------------------------------------------------------------------
Issue #285
[AAA-WG]: Accouting AVP issue...
From: Tony Johansson
Date: Tue Feb 19 14:30:15 2002
All,
In my efforts to update the Diameter MIPv4 application I have stumble on
the Accounting AVPs defined and realized that exactly the same AVPs are
defined also in the NASREQ application, see below.
Unless I have misunderstood something, I would suggest that we move
these AVPs to the Base, since they are used by both NASREQ and MIP.
Regards,
/Tony
In MIP:
"7.1 Accounting-Input-Extended-Octets AVP
The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
Unsigned64, and contains the number of octets in IP packets received
from the user.
7.2 Accounting-Output-Extended-Octets AVP
The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type
Unsigned64, and contains the number of octets in IP packets sent to
the user.
7.3 Accounting-Session-Time AVP
The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32,
and indicates the length of the current session in seconds.
7.4 Accounting-Input-Extended-Packets AVP
The Accounting-Input-Extended-Packets (AVP Code 365) is of type
Unsigned64, and contains the number of IP packets received from the
user.
7.5 Accounting-Output-Extended-Packets AVP
The Accounting-Output-Extended-Packets (AVP Code 366) is of type
Unsigned64, and contains the number of IP packets sent to the user."
In NASREQ:
8.1 Accounting-Input-Extended-Octets AVP
The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
Unsigned64, and contains the number of octets in IP packets received
by the user.
8.2 Accounting-Output-Extended-Octets AVP
The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type
Unsigned64, and contains the number of octets in IP packets sent to
the user.
8.3 Accounting-Session-Time AVP
The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32,
and indicates the length of the current session in seconds.
8.4 Accounting-Input-Extended-Packets AVP
The Accounting-Input-Extended-Packets (AVP Code 365) is of type
Unsigned64, and contains the number of IP packets received by the
user.
8.5 Accounting-Output-Extended-Packets AVP
The Accounting-Output-Extended-Packets (AVP Code 366) is of type
Unsigned64, and contains the number of IP packets sent to the user.
--------------------------------------------------------------------------
Issue #286
From: Tony Johansson
Date: Tue Feb 19 17:40:02 2002
All,
Section 4.11 in the Diameter MIPv4 appl. defines the MIP-Home-Agent-Host
AVP and contains the identity of the home agent requested by the mobile
node in its registration request. This AVP is used by the AAAH to
determine the destination of the HAR.
However, this AVP demands changes to the Mobile IP protocol and looking
back at the Issue 212 thread
(http://www.merit.edu/mail.archives/aaa-wg/2001-11/msg00062.html) the
consensus was to NOT make use of this AVP. The agreed solution for Issue
212 was instead to require that the new AAAH perform the Server
Discovery procedures (defined in the Base) to determine the URL of the
Home Agent.
So, I believe this AVP is an editorial mistake and should just be
removed. Any objections to this?
Regards,
/Tony
--------------------------------------------------------------------------
Issue #287
Issue : Overloaded URI
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: 2/21/02
Reference:
Document: Base
Comment type: T
Priority: S
Section: 4.4
Rationale/Explanation of issue:
Some Background
---------------
The AAA URI provides two different kinds of information.
1. It identifies a Diameter node. A Diameter node is a Diameter
process running on some host or device. It is possible to have
more than one Diameter process running on a host.
2. It provides information about how to connect to the Diameter node
-- what transport protocol to use, what transport level security
to use, and even what AAA protocol to use (although we are only
concerned about one, namely Diameter).
The AAA URI also serves two different purposes.
1. It is used in the peer-to-peer protocol to identify a peer and
indicate certain parameters concerning how to connect to that
peer. This use requires the full URI including the prefix, the
fqdn, the port number, and the options. A URI for this purpose
may be stored in a local configuration file or on a remote server
to enable dynamic peer discovery (see sec. 5.2).
2. It is used in the Diameter routing and forwarding decisions to
identify the Diameter node to which a Diameter message is
addressed. This use requires those portions of the URI that
identify the Diameter node but does not require (and can be
confused by) the information about how to connect to the node as a =
peer. This is the use made of the URI as transmitted in all AVPs
of type DiameterIdentity.
The Problem
-----------
The problem is that the URI format is currently defined in only one
place (sec. 4.4 under the "DiameterIdentity" type) and makes no
distinction between its use for the two different purposes described
above.
Operational Difficulties if the Problem Isn't Fixed
---------------------------------------------------
Section 4.4 states:
Unless a Diameter node is sitting on the border of two routing
domains (e.g. private and public), a Diameter node MUST
advertise the same identity on all connections, via the CER
and CEA's Origin-Host AVP.
Suppose a Diameter node has two peers. It connects to the first peer
using SCTP. It connects to the second peer using TCP. In order to
obey this requirement, the node would have to include the string
"transport=sctp" in the Origin-Host AVP it puts in its CER or CEA
message to the second peer even though it is using TCP to connect to
that peer. So the identity advertised is not the identity used.
This seems odd, but as we shall see, it is actually necessary in order
to make the routing mechanism work.
Section 4.4 goes on to state:
The same identity advertised in a connection's CER and CEA MUST
be used in any AVP of type DiameterIdentity sent on that
connection.
Now suppose an implementor misses the oddity required by the first
sentence and does the obvious thing -- suppose the implementation
always includes in the CER the parameters actually in use on the peer
connection. Then the implementation will have a very hard time
meeting this requirement too. It would have to know how it will
route the message at the time it generates the message, a horrible
violation of modularity. Supposing it does know how it will route
the message and sets the value of the Origin-Host AVP in the message
to the same value used in the CER or CEA sent to the peer to which it
will route it. Now suppose something goes wrong when sending the
message to this peer, and the message is subsequently retransmitted
to a backup peer. Oops. Now the Origin-Host AVP is wrong for that
connection and it can't be changed.
So we'll just have to assume that all implementors pick up on the
oddity. But wait -- we're still not out of the woods. Suppose, at
the time a session begins, the Diameter client supporting the session
uses TCP on its peer link. So it includes the string "transport=tcp"
in the auth request that begins the session. Suppose that several
hours later the session is still in progress, but the client has
reinitialized its peer link and is now using SCTP. Now suppose the
home server sends an Abort-Session-Request message to the client for
this session. The Abort-Session-Request will include a
Destination-Host AVP that contains the string "transport=tcp". The
message eventually reaches the peer connected to the client. The
peer matches the URI in the Destination-Host AVP with the ones in its
peer table. It finds no match because "transport=tcp" does not match
"transport=sctp". So it discards the message.
Interaction With Issue 273
--------------------------
Another issue urges that Diameter nodes not use different port
numbers for TLS versus non-TLS connections. I am guessing that issue
273 is the one that encompasses this change. The question of port
number use for TLS versus non-TLS was raised by Allison Mankin in:
http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00025.html
The outcome of issue 273 (if that is the issue that includes this
question) is critical to the resolution of this issue as well. The
reason is that we use the combination of fqdn and port number to
identify a diameter node. If more than one Diameter node (Diameter
daemon) runs on a host, they will use different port numbers. But if
a Diameter node listens on more than one port number, then it may use
two different URIs and there will be no way for a peer to know that
the URI from the Destination-Host AVP of a message it is routing
matches the URI of one of its peers if the port number differs.
John Loughney suggested use of aaa: vs. aaas: to indicate whether TLS
is used in:
http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html
If this suggestion is adopted, then the "s" in aaas: will need to be
ignored when doing routing matches against entries in the peer table.
Requested change:
Define the format of the URI somewhere other than section 4.4. In
the definition of the DiameterIdentity type in section 4.4, specify
that only the prefix, fqdn, and port number portions of the URI are
included in AVP value fields of this type. The sentences cited above
may now be left in section 4.4 because they no longer cause a
problem.
If the resolution of issue 273 allows a Diameter node to listen on
different ports for TLS vs. non-TLS connections, then section 4.4
needs to emphasize that a single port number MUST be used in all AVPs
of type DiameterIdentity. If the resolution of 273 requires use of
the same port for TLS and non-TLS connections, then it would still be
a good idea to include text in section 4.4 following the first
sentence cited above that emphasizes that the same port number MUST
be used in all AVPs of type DiameterIdentity even if a peer
connection request was received on a different port.
If the URI prefix may either be aaa: or aaas: depending on transport
security, then text should be added to section 6 stating that when
matching URIs for routing purposes, the "s" in aaas: should be
dropped before the compare is made.
--------------------------------------------------------------------------
Issue #288
Subject: [issue] 'M' Bit at fault rules still not right
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: February 25, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:
The AVP Flag rules tables in the various Diameter drafts specify in
which AVPs the 'M' bit MUST be set, in which AVPs it MUST NOT be set,
etc.
However section 4.1 of the base draft states:
A Diameter node that sets the 'M' bit in an AVP that is not
defined in a given message's ABNF is at fault if the message is
rejected.
In the next paragraph it states:
A Diameter node that rejects a message due to an unrecognized AVP
with the 'M' bit set, and the AVP in question is defined in the
message's ABNF, is at fault.
These sentences make the criterion for setting the 'M' bit be whether
or not the AVP is listed in the formal syntax for the message in
which it appears. This is in direct contradiction to the criterion
that the 'M' bit should be set according to the specification in the
AVP Flag rules table of the draft defining the AVP.
Life gets complicated, however, when an AVP defined in one Diameter
Application or a vendor-specific AVP gets included in a message
defined in another Diameter Application. This is allowed for most
Diameter messages because the "* [ AVP ]" construct appears in most
message specifications.
So what happens if the sender of the message considers such an AVP to
be critical to its intent, but the recipient of the message does not
understand the AVP? The answer is that an interoperability failure
happens. Some have argued (I have at times) that Diameter's
open-ended extensibility is actually one of its weaknesses.
At the AAA WG interim meeting in Santa Clara in May 2001, the
extensibility-is-good faction reached a compromise with the
interoperability-failures-are-bad faction that resulted in the at
fault rules that appear in section 4.1 of the base draft. The issue
here is that it is important to get the rules right.
Considering that a Diameter node may include non-standard AVPs, and
considering that it may be critical to the security or business
requirements of the parties involved to know whether or not such AVPs
are accepted and processed, and considering that interoperability
failures are not in the best interests of any of the parties
involved, I propose the following principles to govern setting of the
'M' bit:
1) AVP specifiers should be encouraged to require setting the 'M'
bit of any AVP for which the interest of any of the parties
would be hurt were the AVP to be ignored.
2) Implementors should be required to provide alternatives to
sending non-standard AVPs with the 'M' bit set. These may
include:
a) If a message is rejected because it contains a non-standard
AVP with the 'M' bit set, the implementation may resend the
message without the AVP, possibly inserting additional
standard AVPs instead.
b) A configuration option may be provided on a system wide, per
peer, or per realm basis that would allow/prevent particular
non-standard, Mandatory AVPs to be sent. Thus an
administrator could change the configuration to avoid
interoperability problems.
3) An implementation that does not comply with the above
requirements is not compliant with the Diameter standard.
Examples
--------
Example 1: If I were to define a vendor-specific
Interlink-Wowee-Zowee-Filter-Rule AVP, I would specify that the 'M'
bit MUST be set (I certainly don't want the filters to be ignored).
An implementation sending this AVP would be compliant if, upon
receiving a rejection for a message containing the AVP, it re-sent
the message with the NAS-Filter-Rule AVP in place of the
Interlink-Wowee-Zowee-Filter-Rule AVP. Alternatively, an
implementation could achieve compliance by offering a per-realm
configuration option to control what realms to send the
Interlink-Wowee-Zowee-Filter-Rule AVP to.
Example 2: NASCO NASes always include the NAS-Filter-Rule AVP in
Accounting-Request messages on the theory that inclusion of this AVP
in accounting records may be critical to some providers' auditing
requirements. NASCO is permitted to do this because the construct
"* [ AVP ]" appears in the formal syntax of the Accounting-Request
message. The 'M' bit is set because the table in section 2.1 of the
NASREQ standard requires it. ACME Accounting Servers do not
understand the NAS-Filter-Rule AVP. If they receive an Accounting
Request message for a NASREQ session that includes the
NAS-Filter-Rule AVP with the 'M' bit set, they reject the message.
Thus no accounting can ever happen between a NASCO NAS and an ACME
Accounting Server. Who is at fault? ACME argues that according to
Diameter-08, NASCO is at fault because neither of the tables in
section 10.2 of NASREQ list the NAS-Filter-Rule AVP.
Requested change:
Replace the at fault rules in section 4.1 with the following text.
(Note: the editor may decide to move this discussion to another, more
appropriate section of the draft.)
The 'M' bit MUST be set according to the rules defined for the AVP
containing it. In order to preserve interoperability, a Diameter
implementation MUST be able to exclude from a Diameter message any
Mandatory AVP which is neither defined in the base Diameter
standard nor in any of the Diameter Application specifications
governing the message in which it appears. It MAY do this in one
of the following ways:
1) If a message is rejected because it contains a Mandatory AVP
which is neither defined in the base Diameter standard nor in
any of the Diameter Application specifications governing the
message in which it appears, the implementation may resend the
message without the AVP, possibly inserting additional standard
AVPs instead.
2) A configuration option may be provided on a system wide, per
peer, or per realm basis that would allow/prevent particular
Mandatory AVPs to be sent. Thus an administrator could change
the configuration to avoid interoperability problems.
Diameter implementations are required to support all Mandatory
AVPs which are allowed by the message's formal syntax and defined
either in the base Diameter standard or in one of the Diameter
Application specifications governing the message.
--------------------------------------------------------------------------
Issue #289
Issue : Routing of session messages defined in base
Submitter name: Johan Johansson
Submitter email address: johanj@ipunplugged.com
Date first submitted: 2002-02-26
Reference:
Document: base
Comment type: T
Priority: 1
Section: 10.1, 6.8
Rationale/Explanation of issue:
STR and ASR messages do not belong to any specific application but
rather to all of them. This means that they will take *any* route to
a realm even if it is a dead end. They should contain
Auth-Application-Id avps.
Let the realm R be a realm with (separate) home servers N and M for
NASREQ and MIP and assume that from a given realm the normal route
passes through a node S that has one NASREQ route to R that will
make messages enter R via N and one MIP route that will make
messages enter R via M, e.g.
S----------------X------------X------------N
|
+------------X------------M
Since M and N have no common application they will not be peers.
Assume that there is an active MIP session at M that the access
device determines to terminate by sending an STR. There is nothing
that prevents S from routing the STR down the N path.
Requested changes:
6.8: I haven't thought of a good change to this section yet. But it
should state that messages regarding a session for a particular
application should contain the id of that application.
10.1: Change
+-----------------------------------------------+
| Command-Code |
|---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
to
+-----------------------------------------------+
| Command-Code |
|---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |
I guess the RAR messages should probably also have the
Auth-Application-Id for similar purposes but I'll leave that for
those who actually use it to comment on.
j
--------------------------------------------------------------------------
Issue #290
Issue : Handling of Accounting-Multi-Session-Id AVP
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 02-27-2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00314.html
Document:draft-mobileip-08
Comment type: Technical
Priority:1
Section:
Rationale/Explanation of issue:
Changes to generation & handling of the Accounting-Multi-Session-Id AVP.
The following lines prefixed with "*" are extracted from
draft-mobileip-08. The lines are numbered to make them referencable
in the discussion.
*01 1.2 Inter-Realm Mobile IP
*02
*03 [...]
*04
*05 For new sessions, the AAAH MUST create an accounting session
*06 identifier, which is added to the Accounting-Multi-Session-Id AVP in
*07 the HAR message sent to the home agent.
*08
*09 During the creation of the HAR, the AAAH MUST use a different session
*10 identifier than the one used in the AMR/AMA (see figure 2). Of
*11 course, an AAAH MUST use the same session identifier for all HARs
*12 initiated on behalf of a given mobile node's session. [...]
*13
(1) According to the Introduction, an AAAH may be session-stateless. I
don't think a session-stateless AAAH can differentiate a new session
from a handoff of an existing session. Therefore a session-stateless
AAAH couldn't send the same session-id for handoffs, as stated in line *11.
*14 [...]
*15
*16 Upon receipt of the HAR, the Home Agent first processes the Diameter
*17 message. [...] The Accounting-Multi-Session-Id AVP in
*18 the HAR MUST be included in the HAA, which is then forwarded to the
*19 AAAH.
*20
(2) The last sentence is not quite right. While the HA does send an
Accounting-Multi-Session-Id AVP in the HAA, it may be a different one
than was received in the HAR. (see lines *44-*46).
*25 1.3 Support for Mobile IP Handoffs
*26
*27 [...]
*28
*29 Since the new AAAH in the home network MAY not have access to the
*30 session identifier that was used by the old AAAH, it is necessary for
*31 the resulting HAR received by the HA to be identified as a
*32 continuation of an existing session. If the HA receives an HAR for a
*33 mobile node, with a new session identifier, and the HA can guarantee
*34 that this request is to extend service for an existing service, then
*35 the HA MUST be able to modify its internal session state information
*36 to reflect the new AAAH and session identifier. The HA MUST also
*37 issue an STR message with the old session identifier to the AAAH it
*38 was communicating with when using the old session identifier.
*39
*40 It is necessary for accounting records to have some commonality
*41 across handoffs in order for correlation to occur. Therefore, in the
*42 event that a home agent receives an HAR with a different Accounting-
*43 Multi-Session-id AVP (and obviously a different Session-Id AVP), the
*44 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP
*45 that was received by the AAAH in the first HAR for the mobile's
*46 session. This modified Accounting-Multi-Session-Id AVP will be
*47 returned to the foreign agent by the AAAH in the AMA. Both the
*48 foreign and home agents MUST include the Accounting-Multi-Session-Id
*49 in the accounting messages.
*50
(3) Since the AAAH must be prepared to have the AAAH-generated
Accounting-Multi-Session-Id overridden by the HA, the protocol should
change to just have the HA always specify the
Accounting-Multi-Session-Id.
The thinking is that the HA is constant over the MN's session, while the
AAAHs and AAAFs and FAs change. So the HA is in a position to specify a
constant Accounting-Multi-Session-Id, eliminating the extra
complications of a switcheroo.
The proposal is that the AAAH will not send a
Accounting-Multi-Session-Id in the HAR. The HA MUST send a
Accounting-Multi-Session-Id in the HAA. All of the messages for a
MN's session will have the same value for the
Accounting-Multi-Session-Id AVP.
(4) Since the AAAH may be session-stateless, the HA would send the STR
to the AAAH, as indicated in lines *36-*38, if and only if the AAAH
has changed.
Requested change:
In Section 1.2 Inter-Realm Mobile IP
Replace:
"For new sessions, the AAAH MUST create an accounting session
identifier, which is added to the Accounting-Multi-Session-Id AVP in
the HAR message sent to the home agent.
"During the creation of the HAR, the AAAH MUST use a different session
identifier than the one used in the AMR/AMA (see figure 2). Of
course, an AAAH MUST use the same session identifier for all HARs
initiated on behalf of a given mobile node's session. [...]
With:
"During the creation of the HAR, the AAAH MUST use a different session
identifier than the one used in the AMR/AMA.
"If the AAAH is session-stateful, it should send the same session
identifier for all HARs initiated on behalf of a given mobile node's
session.
"If the AAAH is not session-stateful, it will manufacture a unique
session-id for every HAR. (Note--This will not cause a problem for
the HA, who must be able to recognize a handoff even if the AAAH
thinks the session is new; an AAAH may incorrectly view a session as
new when the handoff AMR goes to a different AAAH than the previous
AMR).
- - - -
In Section 1.2 Inter-Realm Mobile IP
Replace the last sentence of the following paragraph:
Upon receipt of the HAR, the Home Agent first processes the Diameter
message. [...] The Accounting-Multi-Session-Id AVP in
the HAR MUST be included in the HAA, which is then forwarded to the
AAAH.
With:
The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA
returned to the AAAH.
- - - -
In section 1.3 Support for Mobile IP Handoffs
Replace:
Since the new AAAH in the home network MAY not have access to the
session identifier that was used by the old AAAH, it is necessary for
the resulting HAR received by the HA to be identified as a
continuation of an existing session. If the HA receives an HAR for a
mobile node, with a new session identifier, and the HA can guarantee
that this request is to extend service for an existing service, then
the HA MUST be able to modify its internal session state information
to reflect the new AAAH and session identifier. The HA MUST also
issue an STR message with the old session identifier to the AAAH it
was communicating with when using the old session identifier.
It is necessary for accounting records to have some commonality
across handoffs in order for correlation to occur. Therefore, in the
event that a home agent receives an HAR with a different Accounting-
Multi-Session-id AVP (and obviously a different Session-Id AVP), the
home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP
that was received by the AAAH in the first HAR for the mobile's
session. This modified Accounting-Multi-Session-Id AVP will be
returned to the foreign agent by the AAAH in the AMA. Both the
foreign and home agents MUST include the Accounting-Multi-Session-Id
in the accounting messages.
With:
"Since the new AAAH in the home network MAY not have access to the
session identifier that was used by the old AAAH, or since the AAAH
may be session-stateless, it is necessary for the resulting HAR
received by the HA to be identified as a continuation of an existing
session.
"If the HA receives an HAR for a mobile node, with a new session
identifier, and the HA can guarantee that this request is to extend
service for an existing service, then the HA MUST be able to modify
its internal session state information to reflect the (possibly) new
AAAH and new session identifier.
"If the AAAH is new, the HA MUST also issue an STR message with the old
session identifier to the AAAH it was communicating with when using
the old session identifier.
"It is necessary for accounting records to have some commonality across
handoffs in order for correlation to occur. Therefore, the home agent
MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for
the mobile's session. That is, the HA generates a unique
Accounting-Multi-Session-Id when receiving an HAR for a new session, and
returns this same value in every HAA for the session.
"This Accounting-Multi-Session-Id AVP will be returned to the foreign
agent by the AAAH in the AMA. Both the foreign and home agents MUST
include the Accounting-Multi-Session-Id in the accounting messages."
- - - -
In Section 1.5 "Co-located Mobile Node"
Add the following sentence:
"The HA includes the Accounting-Multi-Session-Id AVP in the AMR sent to
the AAAH, as the AAAH may find this a useful piece of session-state or
log entry information."
- - - -
In section 2.3 Home-Agent-MIP-Request
Remove { Accounting-Multi-Session-Id } from the message ABNF.
- - - -
In section 2.4 Home-Agent-MIP-Answer
Change [ Accounting-Multi-Session-Id ] to { Accounting-Multi-Session-Id }
in the message ABNF.
- - - -
In section 8.1 Mobile IP Command AVP Table,
Add an entry for the Accounting-Multi-Session-Id AVP.
Attribute Name | AMR | AMA | HAR | HAA |
------------------------------|-----+-----+-----+-----+
Accounting-Multi-Session-Id | 0-1 | 1 | 0 | 1 |
- - - -
In section 8.2 Accounting AVP Table
Add an entry for the Accounting-Multi-Session-Id AVP.
Attribute Name | ACR | ACA |
------------------------------|-----+-----+
Accounting-Multi-Session-Id | 1 | 0-1 |
--------------------------------------------------------------------------
Issue #291
Remove references to CMS-Cert in cms-sec-03
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: February 26, 2002
Reference:
Document: cms-sec
Comment type: E
Priority: S
Section: many
Rationale/Explanation of issue:
Cms-sec-02 defined an AVP called CMS-Cert.This AVP was removed in
cms-sec-03, however many references to it remain.
Requested change:
Remove all references to the CMS-Cert AVP.
--------------------------------------------------------------------------
Issue #292
Issue :Handling of Home-Agent-In-Foreign-Network flag
Submitter name: Bob Kopacz
Submitter email address: BKopacz@InterlinkNetworks.com
Date first submitted: 02-27-2002
Reference:
Document: draft-mobileip-08
Comment type:Technical
Priority: 1
Section:
Rationale/Explanation of issue:
(1) It is difficult for the originating AAAF to correctly set the
Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a
"real" HA IP address (not all zeroes or all ones). The AAAF only sees
an IP address. The AAAF doesn't know just from the HA's IP address
whether that represents an HA in the home network, or an HA in another
foreign network. And maybe doesn't even know if the IP address is in
his own network.
The AAAF would have to call upon the DNS or other external resources
to make this "home-agent-is-in-a-foreign-network" determination. This
introduces unnecessary delay into the call setup by duplicating work
which the AAAH has to do anyway upon receiving the AMR. That is, when
the AAAH receives the AMR with a specified HA IP address, the AAAH has
to map this IP address into the HA's realm and HA's DiameterIdentity,
which will be used as the Destination-Realm and Destination-Host of
the HAR. Furthermore, the AAAH may be able to make this determination
more quickly than the AAAF, as a session-stateful AAAH may well have
this information at hand as part of his session state.
(2) The proposal here is to make the Home-Agent-In-Foreign-Network flag
one which is not set by the originating-AAAF, but is instead set by
the AAAH. This information will be returned to the originating-AAAF
and FA when the updated feature vector is returned in the AMA.
(3) It may be that the originating AAAF wants to disallow a foreign
HA, or allow a foreign HA but only if the foreign HA is in the
originating AAAF's domain. If this capability is desired, then two
new flags, settable by the originating AAAF, can be added to the
MIP-Feature-Vector:
Foreign-HA-Allowed-In-NonOriginating-Network
Foreign-HA-Allowed-In-Originating-Network
The AAAH, after examining the home agent's IP address and determining
whether the HA resides in the originating network, home network, or
some other foreign network, can examine the two new flags to enforce
the originating AAAF's policy on foreign HAs.
This way, the originating AAAF maintains the ability to place retrictions
on foreign HAs before the call is authorized.
(4) If (3) above is considered something an originating AAAF wouldn't care
about, then these two new flags can be removed from the proposal.
Requested change:
In section 1.2 Inter-Realm Mobile IP
Replace:
If the Mobile Node was successfully authenticated, the AAAH checks if
the Home Agent was located in the foreign realm, by checking the
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If
the flag is enabled, then the Home Agent is located in the foreign
realm then AAAH sends an HAR message to AAAF which contains a MIP-
Reg-Request AVP.
With:
If the Mobile Node was successfully authenticated, the AAAH checks if
the Home Agent is located in a foreign realm. If so, the AAAH sets the
Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.
Only the AAAH may set the Home-Agent-In-Foreign-Network flag.
If the Home Agent is located in a foreign realm other than the
originating realm, and the
Foreign-HA-Allowed-In-NonOriginating-Network flag is zero, then the
AAAH will return an AMA with a Result-Code of
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
If the Home Agent is located in the originating foreign realm, and the
Foreign-HA-Allowed-In-Originating-Network flag is zero, then the AAAH
will return an AMA with a Result-Code of
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
Otherwise, if the Home Agent is in a foreign network, and this is
allowed by both the originating AAAF and the AAAH, then the AAAH sends
an HAR message to foreign HA which contains a MIP-Reg-Request AVP.
- - -
In section 1.4 Allocation of Home Agent in Foreign Network
Remove this paragraph:
In the event that the mobile node requests a home agent in the
foreign network, and the AAAF authorizes its use, the AAAF MUST set
the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
This could happen when the AAA request is sent to "extend" a mobile
node's current session.
- - -
In section 4.5 MIP-Feature-Vector AVP
Replace:
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
is added with flag values set by the Foreign Agent or by the AAAF
owned by the same administrative domain as the Foreign Agent. The
Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR
message it sends to the AAAF.
With:
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
conveys flag values set by the Foreign Agent, the AAAF owned by the
same administrative domain as the Foreign Agent, and the AAAH. The
flags in the MIP-Feature-Vector are updated as the AMR makes it way to
the AAAH, and the updated MIP-Feature-Vector is returned in the AMA.
The Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR
message it sends to the AAAF.
- - -
In section 4.5 MIP-Feature-Vector AVP
To this list of flags:
Flag values currently defined include:
1Mobile-Node-Home-Address-Requested
2Home-Address-Allocatable-Only-in-Home-Realm
4Home-Agent-Requested
8Foreign-Home-Agent-Available
16 MN-HA-Key-Request
32 MN-FA-Key-Request
64 FA-HA-Key-Request
128 Home-Agent-In-Foreign-Network
256 Co-Located-Mobile-Node
Add:
512Foreign-HA-Allowed-In-NonOriginating-Network
1024 Foreign-HA-Allowed-In-Originating-Network
- - -
In section 4.5 MIP-Feature-Vector AVP
Replace:
If the mobile node requests a home agent in the foreign network
either by setting the home address field to all ones, or by
specifying a home agent in the foreign network, and the AAAF
authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-
Network bit to one.
The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and
Home-Agent-In-Foreign-Network flag to one.
When the AAAF receives the AMR message, it MUST first verify that the
sender was an authorized Foreign Agent. The AAAF then takes any
actions indicated by the settings of the MIP-Feature-Vector AVP
flags. The AAAF then MAY set additional flags.Only the AAAF may set
the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network
flags to one. This is done according to local administrative policy.
When the AAAF has finished setting additional flags according to its
local policy, then the AAAF transmits the AMR with the possibly
modified MIP-Feature-Vector AVP to the AAAH.
With:
If the mobile node requests a home agent in the foreign network either
by setting the home address field to all ones, or by specifying a home
agent in the foreign network, and the AAAF authorizes the request, the
AAAF may restrict the HA to certain networks by setting the
Foreign-HA-Allowed-In-NonOriginating-Network and/or the
Foreign-HA-Allowed-In-Originating-Network flag.
The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available to one
and the Foreign-HA-Allowed-In-Originating-Network flag to zero.
When the AAAF receives the AMR message, it MUST first verify that the
sender was an authorized Foreign Agent. The AAAF then takes any
actions indicated by the settings of the MIP-Feature-Vector AVP flags.
The AAAF then MAY set additional flags. Only the AAAF may set the
Foreign-Home-Agent-Available, Foreign-HA-Allowed-In-Originating-
Network, and Foreign-HA-Allowed-In-NonOriginating-Network flags to
one. This is done according to local administrative policy. When the
AAAF has finished setting additional flags according to its local
policy, then the AAAF transmits the AMR with the possibly modified
MIP-Feature-Vector AVP to the AAAH.
--------------------------------------------------------------------------
Issue #293
Relax Service-Type from REQUIRED to RECOMMENDED in nasreq
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 1, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: 1
Section: various
Rationale/Explanation of issue:
Although nasreq-08 is not entirely consistent on this, it seems to require
the Service-Type AVP to appear in all messages.Unfortunately, RADIUS does
not make this requirement.Therefore I am relaxing the requirement in
nasreq from MUST to SHOULD.The alternative would be to add an heuristic to
the RADIUS/Diameter gateway section explaining how a RADIUS to Diameter
gateway should infer the value of the Service-Type based on the attributes
present in the RADIUS message.Being lazy, I opt for relaxing the
requirement.
Requested change:
State that Service-Type SHOULD (rather than MUST) be included, change the
ABNF from "{ Service-Type }" to "[ Service-Type ]", and change the AVP
Ocurrence Tables from 1 to 0-1.
--------------------------------------------------------------------------
Issue #294
Submitter: Jesse Walker
Submitter email address: jesse.walker@intel.com
Date first submitted: March 2, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:
Diameter keying AVPs cannot securely distribute a key for its intended
purpose. While they may be suitable for handing off a key between the
authentication server and the NAS/Access Point, intended for
communications between themselves alone, as constituted today they are
insecure for transferring a session key intended for use between the
NAS/AP and the client. To become secure, the key handoff has to be
enhanced to incorporate additional cryptographic state that can be
used to provide assurances to all these parties involved in the
transaction.
Examples of such state are the information communicated among the KDC and
the communicating parties in the Needham-Schroeder and Otway-Rees
protocols.
>Given that the AS and AP trust each other (assumed), why
>is a reasonable cryptographic protocol (such as CMS or even IPSec) is
>insufficient to protect the transfer of a STA-AP session key from the AS to
>the AP?
There has been in fact ample discussion around exactly these points. There
is, for instance, the whole key handoff discussion, of which AS-AP handoff
is a special case. As a second example, there is the flap around the
Arbaugh-Mishra 802.1X paper, which echos many of our key handoff
discussions, and which we have also discussed.
But even if we had never discussed these points before, we would be forced
to if the issue were raised; if someone perceives holes in our security,
then these have to be addressed, and making an appeal that this wasn't ever
an issue before doesn't help.
I don't buy the assumed trust argument, because it is not specific enough to
offer any useful insight. Let me respond to it by asking why should we
assume the AS and the AP trust each other, and, more to the point, for what
purpose should they trust each other? I think the correct assumptions are
something like
a. The AS and the AP share a key used for key distribution, and that both
parties can be trusted to use this key for no other purpose, and to expose
it to no other parties;
b. The AS can be trusted to distribute a fresh key whenever it distributes a
key.
Why should we assume substantially more about the AP-AS relationship? Each
assumption represents a new point of attack if compromised, so we would do
well to think about eliminating as many assumptions as possible.
Protocols exist that would allow us to reduce the number of assumptions we
make by incorporating explicit verification in place of trust assumptions.
It is feasible to add protocol state allowing the AS to verify that the key
distribution request really did originate with a legitimate station and not
as the result of a rogue AP or a rogue station. It is feasible for both the
AS and the station to verify that the key distribution is live, even though
they can't verify it is fresh (that's why we have to make the second trust
assumption). It is feasible for both the AP and the station to verify that
the AS intended to distribute this particular key to this particular pair, i.e., that each is talking to the other intended recipient of
the key, and to no one else, and for the protocol to protect against either
the AP or the station cheating (except by exposing a key). The existing
method of throwing keys over the fence to the AP does not have any of these
guarantees built in, so we have to assume much more to use it. Each such
assumption may reasonable in a sufficiently constrained environment, but I
question whether together they are reasonable in a network as open as a
WLAN.
And I don't buy basing the security on mechanisms like IPsec. By definition,
IPsec provides bilateral security between the two parties sharing a security
association, and binds only the two together. A key distribution protocol of
the sort we are discussing is not a bilateral relationship. Key distribution
is a trilateral relationship among three parties--the AS, the AP, and the
station--and because of this will have to cryptographically bind the three
parties together somehow to be secure, i.e., to minimize points to attack.
You can replace IPsec by any other bilateral security protocol, and the same
argument obtains.
My position is that it would be prudent for us to look at adapting a key
distribution protocol that reduces our exposure by minimizing security
assumptions. I believe this because we are building systems that expose many
more attack points than in the past. Indeed, I think the burden of proof is
on the other foot: what leads us to think the special conditions and
circumstances and topologies that permitted security shortcuts in the past
are still applicable in the more fragile environments we are building today?
Why should the mechanisms that worked in more restricted environments still
be applicable unchanged when moved into new environments that, on the
surface at least, seem to violate many of the assumptions we made before?
Proposed change:
A three-way handshake should be incorporated so that key distribution and
confirmation can be dealt with uniformly across multiple environments.
These key distribution methods require active participation by three
parties instead of two.
--------------------------------------------------------------------------
Issue #295
More NASREQ AVPs needed
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: NASREQ-09
Comment type: T
Priority: S
Section: various
Rationale/Explanation of issue:
There are a number of attributes defined in RADIUS RFCs that are
needed for the correct operation of the Diameter NASREQ application.
They are:
CODE NAME RFC
--------- ------------------ ----
29 Termination-Action 2865
41 Acct-Delay-Time 2866
51 Acct-Link-Count 2866
55 Event-Timestamp 2869
78 Configuration-Token 2869
85 Acct-Interim-Interval 2869
87 NAS-Port-Id 2869
88 Framed-Pool 2869
95 NAS-IPv6-Address 3162
98 Login-IPv6-Host 3162
Note: These AVPs were not added to nasreq-09, so this issue requires
more work in nasreq.
Requested change:
Add these attributes to nasreq as Diameter AVPs.
--------------------------------------------------------------------------
Issue #296
Possible new AVP for MobileIPv4
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: MobileIPv4
Comment type: T
Priority: 2
Section:
Rationale/Explanation of issue:
The following attribute is defined in RADIUS for use in accounting
messages.It might be useful in the MobileIPv4 application.
CODE NAME RFC
--------- ------------------ ----
55 Event-Timestamp 2869
Requested change:
Consider adding this attribute to MobileIPv4 as a Diameter AVP.
Note: This AVP will need to be defined in NASREQ for RADIUS
compatibility. See issue TBA.
--------------------------------------------------------------------------
Issue #297
NASREQ-specific values for Termination-Cause AVP
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 4, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
The RADIUS Acct-Terminate-Cause attribute (#49) is superseded in
Diameter by the Termination-Cause AVP (#295).However, there are
many values defined for Acct-Terminate-Cause that have no counterpart
in Termination-Cause.Many of these values are nasreq-specific.
Requested change:
Define addional values in nasreq for the base draft's
Termination-Cause AVP to cover the semantics of the RADIUS
Acct-Terminate-Cause attribute.Ensure that all values
for Acct-Terminate-Cause listed in IANA's radius-types.txt are
covered.Specify the mapping between the Acct-Terminate-Cause
values and the Termination-Cause values so that a RADIUS/Diameter
gateway can translate between them.
--------------------------------------------------------------------------
Issue #298
Issue : Minor corrections to mobileip-09
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-04-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
Minor editing corrections.
Requested change:
The NASREQ draft has a section "Legacy RADIUS Attributes" with text
along the lines of "The Diameter protocol reserves the AVP Codes 0-255
for "legacy RADIUS" support.The following table contains the RADIUS
attributes supported by this Diameter application, their AVP code
values, types, possible flag values and whether the AVP MAY be
encrypted. RADIUS attributes not listed are not supported by the
Diameter protocol."
After section 4.0 Mandatory AVPs, create a similar section 4.1 which
says something like the following (to indicate the subset of RADIUS
attributes a Diameter Mobile-IP client/server requires in its
dictionary):
> 4.1 Supported Legacy RADIUS Attributes
>
> The Diameter protocol reserves the AVP Codes 0-255 for "legacy RADIUS"
> support.The base protocol defines the RADIUS attributes User-Name,
> Session-Timeout, Acct-Session-Time, Acct-Multi-Session-Id, Proxy-State,
> and Class, all supported by this Diameter application.This application
> supports these RADIUS attributes and no others.
- - -
In section 4.3MIP-Mobile-Node-Address AVP
> The Mobile-Node-Address AVP (AVP Code 333) is of type IPAddress and
^^^^^^^^^^^^^^^^^^^
Change to "MIP-Mobile-Node-Address"
- - -
In section 4.4MIP-Home-Agent-Address AVP
> The Home-Agent-Addess AVP (AVP Code 334) is of type IPAddress and
^^^^^^^^^^^^^^^^^
Change to "MIP-Home-Agent-Address"
- - -
In section 4.5MIP-Feature-Vector AVP
> Whenever the Foreign Agent sets either the Mobile-Node-Home-Address-
> Requested flag or the Home-Agent-Request flag to one, it MUST set the
^^^^^^^^^^^^^^^^^^
Change to "Home-Agent-Requested"
- - -
In the following, move the 5.5.1 section header down by one paragraph,
i.e.
Change:
> 5.5Distributing the Foreign-Home Session Key
>
> 5.5.1 Home Agent in the home network
>
> If the home agent is in the home realm, then the AAAH has to generate
> the Foreign-Home session key. Otherwise, it is generated by the AAAF.
>
> In the cases when the AAAH generates the Foreign-Home session key,
> ...
To:
> 5.5Distributing the Foreign-Home Session Key
>
> If the home agent is in the home realm, then the AAAH has to generate
> the Foreign-Home session key. Otherwise, it is generated by the AAAF.
>
> 5.5.1 Home Agent in the home network
>
> In the cases when the AAAH generates the Foreign-Home session key,
> ...
- - -
In section 6.6MIP-MN-to-HA-Key AVP
> * [ AVP ].fi
Remove ".fi"
- - -
In section 11.1Normative References
> [DIAMBASE]P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens,
> "Diameter Base Protocol", draft-ietf-aaa-diameter-08.txt,
> IETF work in progress, November 2001.
Change to draft-10 (or maybe draft-11 for the next revision)
> [MOBILEIP] C. Perkins, Editor. IP Mobility Support.
>RFC 2002, October 1996.
RFC2002 has been obsoleted by RFC3220, January 2002.
> [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security
> Application", draft-ietf-aaa-diameter-cms-sec-03.txt,
> IETF work in progress, November 2001.
Change to draft-ietf-aaa-diameter-cms-04.txt (or maybe -05 for next revision)
> [MIPKEYS]C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile
>IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work in
>progress, July 2001.
The above has expired, but key-09, 26 February 2002, is out.
--------------------------------------------------------------------------
Issue #299
Issue : Need more explanation about handling MN handoffs
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-04-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
I may be missing something significant here, but ...
This issue has to do with how an AAAF and AAAH, when given a Home
Agent's IP address, derive the domain/realm/DiameterIdentity
information needed by the Diameter AAA servers.
This issue may also have some bearing on the relationship between a
DiameterIdentity and a FQDN.
Unfortunately I don't have a good solution to present, so I'm
indicating what the problems are, as indicated by "-->".It may
be that the solution is to enhance the Mobile IP protocol to
provide more information in the Registration Request.
THE AAAF's PROBLEM:
------------------
Section 1.4. Allocation of Home Agent in Foreign Network, says
the following:
> 1.4Allocation of Home Agent in Foreign Network
>
> [...]
>
> In the event that the mobile node requests a home agent in the
> foreign network, and the AAAF authorizes its use, the AAAF MUST set
> the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
> This could happen when the AAA request is sent to "extend" a mobile
> node's current session.
>
-->(1) I think some text needs to be added to describe how the AAAF
determines if the HA is in a foreign network.
That is, I am guessing the method is along these lines:
Suppose a MN initially connects, is allocated an HA, and later
undergoes a handoff to a new FA and new AAAF.Depending on the MN's
new point of attachment, the new FA and AAAF may or may not be in
the same foreign domain as before, or the foreign domain may
be same but the AAAFs are different, or the handoff may involve
the same AAAF as before.
In the AMR, the new AAAF is provided with the MN user's NAI and the
HA's IP address.Say the MN user is "bob@donut.com" and the specified
HA IP address is 1.2.3.4.
The new AAAF does a reverse DNS lookup of tbe HA's IP address,
1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds
to an FQDN of "homeagent86.westcoast.spinach.com".
Now the AAAF extracts the realm part of the NAI, "donut.com", and
pre-pends a dot, coming up with ".donut.com".The AAAF then checks
if this ".donut.com" string is a trailing substring of the
"homeagent86.westcoast.spinach.com" FQDN.It isn't, so the AAAF
concludes the HA is in a foreign network and sends the
Home-Agent-In-Foreign-Network flag with a value of one.If the tail
of the FQDN matched ".donut.com", the AAAF would conclude the HA was
in the home network.
-->(2) This may or may not be anywhere close to the AAAF's method.
At any rate, the method should be described in sufficient detail
for an AAAF implementation.
-->(3) If this DNS reverse lookup is indeed the AAAF's method to
make this "home-agent-is-in-a-foreign-network" determination, then
this introduces a delay into the handoff, and should probably be
noted.
THE AAAH's PROBLEM
------------------
Section 1.2 Inter-Realm Mobile IP, says the following:
>
> 1.2Inter-Realm Mobile IP
>
> [...]
>
> If the Mobile Node was successfully authenticated, the AAAH checks if
> the Home Agent was located in the foreign realm, by checking the
> Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.If
> the flag is enabled, then the Home Agent is located in the foreign
> realm then AAAH sends an HAR message to AAAF which contains a MIP-
> Reg-Request AVP.
Continuing the example, suppose the AAAF has determined that the
HA is in a foreign network, and has forwarded the AMR to the home
realm.The AAAH receives the AMR, and the AMR indicates the HA's
address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON,
and the User-Name is "bob@donut.com".
-->(4) Now the AAAH wants to send an HAR to the HA.But Diameter
routes by Destination-Realm and Destination-Host, not by IP address,
so the AAAH has to somehow come up with the HA's DiameterIdentity
for the Destination-Host AVP of the HAR, and the HA's realm for the
Destination-Realm of the HAR.
AAAH's 1st Problem: How to discover the HA's DiameterIdentity:
If the AAAH maintains session-state, then this HA identity
information can be part of the cached session-state information,
and there may be no problem.But there is a problem if either
(a) the AAAH is not session-stateful, or (b) the AAAH is
session-stateful but has no session-state info because the handoff
AMR is received by a different AAAH than the AAAH which received
the original AMR for the session.
So if we have case (a) or (b), the hapless AAAH is holding the HA's
IP address, and needs to come up with the HA's realm and
DiameterIdentity.The method might be along these lines:
The AAAH can do a reverse lookup of the IP address 1.2.3.4, and
again DNS returns an FQDN of "homeagent86.westcoast.spinach.com"
*If* the DiameterIdentity is the same as the FQDN, then the AAAH
constructs the HAR's Destination-Host =
"homeagent86.westcoast.spinach.com". (An aside: I haven't kept up
with the recent DiameterIdentity thread, but I thought the
DiameterIdentity needed to be something like "FQDN+extra", so that
multiple Diameter applications could run on the same box.In
which case the FQDN isn't sufficient).
AAAH's 2nd Problem: How to discover the HA's Realm:
The AAAH still needs to derive the HAR's Destination-Realm, from
the FQDN.The realm is probably either "westcoast.spinach.com"
or "spinach.com".Does the AAAH have a way to know for sure, or
is the best-guess algorithm to say that the realm is what
follows the next-to-last dot of the FQDN, e.g. "spinach.com".
-->(5) Again, this may or may not be anywhere close to what the
AAAH needs to do to surmise the HA's realm and identity.At any
rate, the method should be described in sufficient detail to
implement an AAAH.
-->(6) If this DNS reverse lookup is indeed part of the AAAH's
method, then this introduces a delay (maybe a 2nd delay depending on
what the AAAF had to do) into the handoff, and should probably be
noted.
-->(7) It seems the AAAF and AAAH are both starting from scratch
with the HA's IP address, and duplicating efforts and delays. Maybe
the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF
possesses) could be passed along to the AAAH.
--------------------------------------------------------------------------
Issue #300
Issue: EAP corner conditions
Submitter: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: March 5, 2002
Reference:
Document: NASREQ
Comment type: T
Priority: S
Section: 4.0
Rationale/Explanation of issue:
NASREQ has some corner conditions that have turned out to be a big
headache. These occur when the encapsulated EAP Message does not agree
with the Diameter message within which it is encapsulated. These problems
are inherited from RFC 2869.
NASREQ needs to make clear, as RFC 2865 does, that a NAS makes its
access decision based on the Diameter message alone (Accept or Reject),
*not* based on the contents of any enclosed attributes, including an
EAP-Message attribute. This makes sense, since the NAS acts as a
"passthrough" for EAP.
However, this makes for some interesting corner conditions, because
the following packets may be sent by the Diameter server:
a. Accept/EAP-Message/EAP-Failure
b. Reject/EAP-Message/EAP-Success
c. Accept/EAP-Message/Notification
d. Reject/EAP-Message/Notification
e. Accept (no EAP Message)
f. Reject (no EAP Message)
g. Accept/EAP-Message/EAP-Failure, Reply-Message
h. Accept/EAP-Message/EAP-Success, Reply-Message
i. Reject/EAP-Message/EAP-Failure, Reply-Message
j. Accept/EAP-Message/EAP-Success, Reply-Message
k. Challenge/EAP-Message/EAP-Success
l. Challenge/EAP-Message/EAP-Failure
There are probably more corner conditions than this, but my fingers are
getting tired :(
a. Message a is a problem because the Accept says "grant access" while the
Failure, if passed on to the EAP peer will make it think that
authentication has failed. If there are alternate indications of
success, one might argue that the peer will eventually figure it
out. For media in which there are no such indications (IEEE 802 and 802.11
are examples), a timeout will result.
b. Message b is a problem because the Reject says "no access" while the
EAP-Success passed to the peer makes it think it is successful.
If there are alternate indications of Failure on a given media, the peer
may eventually figure things out. On IEEE 802.11 a Disassociate from the
AP would put things right, as would an LCP-Terminate in PPP. On wired IEEE
802 there is no alternate indication of failure, so a timeout will result.
c-d. These are an issue since the peer receives a displayable
Notification, but no indication of Success/Failure. Alternate indications
might help, but for media in which they don't exist, a timeout will
result.
e-f. Ditto, except no notification.
g-j. These are a problem since it is not clear within NASREQ how a
Reply-Message is to be handled within an EAP conversation. Some NAS
implementations translate Reply-Mesage to an EAP-Notification, resulting
in the NAS having*two* EAP messages to send to the peer. Some NAS
implementations treat the Reply-Message as a terminal non-ACK'd message,
in which case the subsequent EAP-Message attributes are never sent. Which
interpretation is correct?
If you're in the "translate to Notification" camp, then presumably the
Notification has to be sent first, since the Success/Failure message
terminates the conversation and therefore nothing can be sent after
that. Note that the Reply-Message doesn't come with an Identifier field,
so presumably the NAS has to make one up. But since the Success/Failure
already has an Identifier field in it, what is the NAS/AP
supposed to do, particularly if the Identifier field is incremented
sequentially? The problems are obviously worse if the Reply-Message is
sent in the middle of the conversation, so that a simple Identifier swap
wouldn't work.
k-l. These are problematic because an Access-Challenge indicates a
continuing conversation, but an EAP-Success/EAP-Failure is a terminating
message. Therefore the Diameter Server will not receive a response to
these messages -- but the NAS will neither have granted nor rejected
access.
Proposed change:
Here are some possible ways to address the Reply-Message issue:
1. On the Reply-Message processing issue, we could suggest that the right
way to notify the EAP peer in an EAP conversation is to use
EAP-Notification instead of Reply-Message, and that Reply-Message is a
terminal message that is sent, and not translated to EAP-Motification.
2. Alternatively, we could specify that Reply Message is to be translated
to EAP-Notification by an EAP capable NAS (what about one which isn't EAP
capable?).
Here are some approaches to addressing the issue of a mismatch between the
RADIUS message (accept/reject) and the EAP-Message attribute:
1. "Dr., it hurts when I do this". This approach says: these corner
conditions are difficult to handle for media in which there are no
alternate failure/success indications, so that NASREQ should state
that Diameter servers SHOULD NOT (MUST NOT?) send these messages. Since an
Diameter server can be assumed not to send these messages, the NAS can
blithely decapsulate and send whatever is inside an
EAP-Message attribute, if one is present, then act on the Diameter message
(Accept/Reject). In this approach, NASREQ states that a
Challenge MUST NOT contain an EAP-Success/Failure message, and that
if a Reply-Message needs to be sent, then this should be encapsulated in
a packet with no EAP-Message attribute, adding an extra round-trip; the
Reply-Message is translated to EAP-Notification, and an
Access-Request/EAP-Message/Notification-Response is sent back to the
Diameter server, after which the EAP conversation continues.
2. "Mr. NAS will make it better". This approach says: the NAS should make
sure these corner conditions will not occur by "manufacturing" EAP
Success packets on receipt of an Access Accept, and "manufacturing" EAP
Failure packets on receipt of an Access Reject. This handles cases a-f,
but has some undesirable implications for cryptographically protected EAP.
In proposals to cryptographically protect EAP (such as EAP TTLS or PEAP),
it is desirable to have as much of the EAP conversation as possible be
protected. The idea of these protocols is to create an encrypted channel,
then complete the EAP conversation within that channel. That means that in
theory the final Success/Failure message is sent down the encrypted
channel.
Since EAP Success/Failure messages are not ACK'd, such a message, if sent,
must terminate the EAP conversation. This implies that they must be the
last message sent, and so if the NAS is to know the result of the
conversation, then they need to be sent within an Access Accept or Reject
message.
But if the "Mr. NAS will make it better" approach is taken, then the NAS
will swallow the encrypted Success/Failure packet and replace it with a
cleartext Success/Failure. This undermines the concept of protection,
which is to be able to authenticate and encrypt each packet in the EAP
conversation.
So it seems to me that, to address these issues in NASREQ, we
need to do one of two things:
1. If we adopt the "Dr., it hurts when I do this" approach, then we need
to suggest changes to the 802.1X state machine to conform to NASREQ. In
this approach, we would presumably leave the EAP
Success/Failure messages as they are in RFC 2284, forbid the bad messages,
and add some text on how Reply-Message attributes are to be processed
within an EAP conversation.
2. If we adopt the "Mr. NAS will make it better" approach, then we may
need to introduce new ACK'd Success and Failure messages within EAP. Doing
this will ensure a response to the success/failure indication, removing
the need for "alternative indications" and ensuring that the encrypted
Success/Failure indication gets through.
--------------------------------------------------------------------------
Issue #301
Issue : Securing the AAAH-generated session keys
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-05-2002
Reference:
Document: draft-mobileip-09
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
The draft-mobileip-09 was updated per issue#266.Issue#266
addressed the case where the HA was in a foreign network, the
destination AAAF generated the FA-HA key, and the destination AAAF
wanted to use CMS to return the key to the FA in a secure manner.
Because the mobility agents may not support CMS (CMS is a SHOULD for
clients but a MUST for servers), the issue#266 solution was for the
destination AAAF (i.e. the HA's AAAF) to set up a DSA with the
originating AAAF (i.e. the FA's AAAF), and to pass the CMS-encrypted
FA-HA key to the originating AAAF within a CMS-Encrypted-Data AVP.
The key is thus hidden as it traverses the home domain and any
intermediary proxy/relay AAA servers.
Issue#266 was retricted to the case of CMS-securing the
AAAF-generated session key.There is a similar need to CMS-secure
the AAAH-generated session keys, if there are intervening proxy
networks between the home network and the mobility agent's network.
The proposal here is for an AAAH who wants to CMS-secure its
generated session keys, to set up a DSA with the mobility agent's
local AAAF, and to pass the CMS-secured keys to the AAAF a la
issue#266.
AAAH-generated keys destined for the FA: An AAAH-generated FA-MN key
(and maybe an AAAH-generated FA-HA key) is returned to the FA in the
AMA, which possibly traverses intermediary proxies.The AAAH can
CMS-secure these keys by setting up a DSA with the FA's local AAAF,
and passing the CMS-encrypted keys to the AAAF a la issue#266.The
AAAH knows the identity of the originating AAAF because this is
kindly provided in the AMR's MIP-Originating-Foreign-AAA AVP.
AAAH-generated keys destined for a foreign HA: The AAAH-generated
HA-MN key is forwarded in the HAR to the HA.If the HA resides in a
foreign network, the HAR may traverse intermediary proxies, and the
AAAH may want to CMS-secure this key.Unfortunately the AAAH
doesn't necessarily know who the destination AAAF is.The problem
here is that the AAAH wants to set up the DSA before forwarding the
HAR which carries the encrypted keys.In this case, I am currently
stuck and soliciting suggestions.(One goofy notion, whose only
virtue is that it works, is this: The AAAH sends a "half-baked" HAR
which doesn't contain the keys.The AAAF receives this half-baked
HAR, extracts the AAAH's identity from the half-baked HAR, sets up a
DSA with the AAAH, who resends a fully-baked HAR with the
CMS-encrypted keys.Unfortunately, this entails another round
trip.)
Requested change:
In section 5.0Key Distribution Center
> 5.0Key Distribution Center
>
> [...]
>
> If the AAAH does not communicate directly with the foreign agent, and
> it does not wish for intermediate proxies to have access to the
> session keys, they SHOULD be protected using the CMS security
> application [CMS].
Change the first sentence to :
"If the AAAH does not communicate directly with one or both
mobility agents,..."
- - -
In section5.2Key Material vs. Session Key
> 5.2Key Material vs. Session Key
>
> [...]
>
> The session keys destined for mobility agents may be encoded using
> the security association available between the AAA server and the
> agents (e.g. IPSec, TLS, CMS).
Change the above sentence to:
"The session keys destined for mobility agents may be encoded using
the security association available between the AAA server and the
agents (e.g. IPSec, TLS, CMS), or, if the AAAH suspects a foreign
mobility agent doesn't support CMS, by using the security
association available between the AAAH and the AAA server hosting
the mobility agent."
- - -
In section 5.3Distributing the Mobile-Home Session Key
> 5.3Distributing the Mobile-Home Session Key
>
[Need some text here to address the case where the HA is in a foreign
network, the HA doesn't support CMS, and the AAAH wants to set up a
DSA with the destination AAAF, and pass the CMS-encrypted HA-MN key
to the destination AAAF.]
- - -
In section 5.4Distributing the Mobile-Foreign Session Key
> 5.4Distributing the Mobile-Foreign Session Key
>
> The Mobile-Foreign session key material is also generated by AAAH
> (upon request) and is added to the MIP-MN-to-FA-Key AVP, which is
> added to the HAR, and copied by the home agent into a Generalized MN-
> FA Key Reply Extension [MIPKEYS] to the Mobile IP Registration Reply
> message, using the SPI proposed by the Mobile Node in the MN-FA Key
> Request From AAA Subtype extension. Further, the home agent includes
> the SPI in the HAA's MIP-FA-to-MN-SPI AVP. The AAAH includes the
> session key in the MIP-FA-to-MN-Key AVP in the HAA, which contains
> the session key used by the foreign agent in the computation of the
> Mobile-Foreign authentication extension.
>
> 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 (home agent in
> foreign domain), 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.If the MIP-FA-to-MN-Key AVP was present in the AMA, the
> foreign agent MUST include the Mobile-Foreign authentication
> extension in the Registration Reply, using the newly distributed key.
Append the following paragraph:
"If the AAAH is returning an FA-HA or FA-MN key to the FA, and the
AAAH wants to secure these keys because the originating AAAF is not
a peer (there are intermediate proxies), the AAAH first sets up a
DSA with the originating AAAF, and passes the FA's key(s) within a
CMS-Encrypted-Data AVP in the AMA."
--------------------------------------------------------------------------
Issue #302
Issue :Combine occurrence rules tables with message ABNF
Submitter name: Bob Kopacz
Submitter email address:bkopacz@interlinknetworks.com
Date first submitted: 03-05-2002
Reference:
Document: all drafts
Comment type: Technical
Priority: 1
Section:
Rationale/Explanation of issue:
1. There are often conflicts between the message ABNF and the
[redundant] information in the occurrence rules tables.Combining
the message ABNF with the occurrence rules would create one location
for the message AVP occurrence information, and eliminate the
redundancies and neverending conflicts.
2. The current ABNF is a little tricky, in that the default number
of occurrences depends on the type of braces around the AVPs.So
replace the and the *'s with the explicit counts as in the
occurrence rules, e.g. 0, 0+, 0-1, etc.Then we don't need both the
{}braces and the []braces, as the numeric counts indicate required
versus optional.
For example, the current ABNF for the AA-Mobile-Node-Request is:
> ::= < Diameter Header: 260, REQ, PXY >
>< Session-Id >
>{ Auth-Application-Id }
>{ User-Name }
>{ Destination-Realm }
>{ Origin-Host }
>{ Origin-Realm }
>{ MIP-Reg-Request }
>{ MIP-MN-AAA-Auth }
>[ Destination-Host ]
>[ Origin-State-Id ]
>[ MIP-Mobile-Node-Address ]
>[ MIP-Home-Agent-Address ]
>[ MIP-Feature-Vector ]
>[ MIP-Originating-Foreign-AAA ]
>[ Authorization-Lifetime ]
>[ Auth-Grace-Period ]
>[ Auth-Session-State ]
>[ MIP-FA-Challenge ]
>[ MIP-Candidate-Home-Agent-Host ]
>* [ AVP ]
>* [ Proxy-Info ]
>* [ Route-Record ]
The occurrence rule tables could be absorbed into the message ABNF
(and eliminated), with a message ABNF that looks like:
> ::= < Diameter Header: 260, REQ, PXY >
>1 < Session-Id >
>1 [ Auth-Application-Id ]
>1 [ Destination-Realm ]
>1 [ MIP-Reg-Request ]
>1 [ MIP-MN-AAA-Auth ]
>1 [ Origin-Host ]
>1 [ Origin-Realm ]
>1 [ User-Name ]
>0-1 [ Authorization-Lifetime ]
>0-1 [ Auth-Grace-Period ]
>0-1 [ Auth-Session-State ]
>0-1 [ Accounting-Multi-Session-Id ]
>0-1 [ Destination-Host ]
>0-1 [ MIP-Candidate-Home-Agent-Host ]
>0-1 [ MIP-Originating-Foreign-AAA ]
>0-1 [ MIP-FA-Challenge ]
>0-1 [ MIP-Feature-Vector ]
>0-1 [ MIP-Home-Agent-Address ]
>0-1 [ MIP-Mobile-Node-Address ]
>0-1 [ Original-State-Id ]
>0+[ Proxy-Info ]
>0+[ Route-Record ]
>0 [ Acct-Application-Id ]
>0 [ Error-Message ]
>0 [ Error-Reporting-Host ]
>0 [ MIP-FA-to-HA-Key ]
>0 [ MIP-FA-to-HA-SPI ]
>0 [ MIP-FA-to-MN-Key ]
>0 [ MIP-FA-to-MN-SPI ]
>0 [ MIP-Filter-Rule ]
>0 [ MIP-Foreign-Agent-Host ]
>0 [ MIP-HA-to-FA-Key ]
>0 [ MIP-HA-to-MN-Key ]
>0 [ MIP-Key-Lifetime ]
>0 [ MIP-MN-to-FA-Key ]
>0 [ MIP-MN-to-HA-Key ]
>0 [ MIP-Reg-Reply ]
>0 [ Redirect-Host ]
>0 [ Redirect-Host-Usage ]
>0 [ Redirect-Max-Cache-Time ]
>0 [ Result-Code ]
>0 [ Re-Auth-Request-Type ]
>0 [ Session-Timeout ]
>0+[ AVP ]
3. This is not a significant change to the drafts.
Requested Change:
Do this in all the Diameter drafts.
--------------------------------------------------------------------------
Issue #303
Security model for peer discovery and redirect
Submitter name: David Spence
Submitter email address: DSpence@Interlinknetworks.com
Date first submitted: March 6, 2002
Reference:
Document: Base
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
While I haven't studied studied base-10 in great detail yet, I
believe there are still significant security issues with peer-to-peer
connections that need to be addressed.
Two of the models for using Diameter that I'm not particularly
thrilled with and admittedly haven't devoted a whole lot of thought
to in the past are the peer discovery and redirect models.
Nevertheless, it is extremely important that if we include these
models in Diameter, we need to make them work.The thing that both
of these models share is that peer-to-peer connections are created
dynamically.This raises two problems.The first is, what makes the
connection originator feel comfy about seeking to establish the
connection?The second is, what makes the connection recipient feel
comfy about accepting the connection?
Consider the redirect model.If Bob@donut.com dials in to
wondernet.net, the wondernet AAA server, aaaf.wondernet.net, sends an
authentication/ authorization request to his redirect agent,
aaa.omniscient.com.Aaa.omniscient.com redirects him to
aaah.donut.com.Aaaf.wondernet.net is comfy because he trusts
aaa.omniscient.com.Aaah.donut.com receives a CER from
aaaf.wondernet.net.Perhaps aaa.omniscient.com trusts
aaah.donut.com, too.But that doesn't help him because the CER has
nothing in it even claiming that the connection is being created
because of a redirect from aaa.omniscient.com, let alone proving it.
-->(1)A major weakness with the redirect model is that the recipient
does not even know who made the referral.
Now consider the server discovery model. Bob@donut.com dials in to
wondernet.net, and the wondernet AAA server, aaaf.wondernet.net, does
a DNS lookup to discover that the AAA server for donut.com is
aaah.donut.com.What good does that do aaaf.wondernet.net?How does
aaaf.wondernet.net even know whether wondernet and donut have a
business relationship?If they do have a business relationship, then
why is it so hard to configure aaah.donut.com into
aaaf.wondernet.net's peer table?So what good is peer discovery?
-->(2)A problem with peer discovery is that a server doing it must
have an independent means of knowing what realms it may make
peer connections to.
Assuming aaaf.wondernet.net does have enough configuration
information to feel comfy establishing a peer-to-peer connection with
aaah.donut.com, we still have the same problem with had with the
redirect model: How does aaah.donut.com know it's o.k. to receive a
connection from aaaf.wondernet.net?
In either model, if a Diameter server receives a CER from a Diameter
node that is not hard configured into its peer table, then we need to
ensure that some form of peer-to-peer security is in place.It
cannot assume that such a connection is IPsec protected.So it must
insist on TLS.But this is nowhere stated.
-->(3)A Diameter node receiving a CER request from another Diameter
node that is not hard configured into its peer table MUST
reject the CER if it does not arrive on a TLS-secured transport
connection.
Some may assume that the successful establishment of a TLS connection
provides sufficient warm fuzzies to both parties to the connection
for them to want to bring up a peer-to-peer link and transfer
Diameter messages over it.I am not convinced that that is a
reasonable assumption except perhaps in some very constrained cases.
These constraints need to be fully described in the security
considerations section.
-->(4)The limitations in the use of TLS to establish trust need to be
understood and clearly stated.
Requested change:
I think the usefulness of the redirect and server discovery models
ought to be reexamined in light of the security problems they
introduce.It may be that removing redirect and server discovery
from Diameter is the best solution.
If the working group believes that redirect and server discovery are
really needed and still useful when constrained to operate securely,
then their use needs to the subject of a genuine security analysis.
These capabilities are not present in RADIUS and they greatly
complicate peer-to-peer security.In RADIUS a node will only
exchange messages with other nodes with which it is configured to
communicate.If Diameter introduces dynamic peer-to-peer
connections, a new trust model must be created or else the entire AAA
infrastructure is at risk.
--------------------------------------------------------------------------
Issue #304
Allowance for temporary peer connections
Submitter name: Ghadiyaram Venkata, David Spence
Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, DSpence@Interlinknetworks.com
Date first submitted: March 6, 2002
Reference:
Document: Base
Comment type: T
Priority: 1
Section:
Rationale/Explanation of issue
A CER received from a previously unknown peer (such as would happen as a
result of peer discovery or a redirect) does not contain complete
information as to how the recipient could recreate the peer connection if it
is lost.
Requested change:
Add the following text:
"If a CER from and unknown peer is answered with a successful CEA, the
lifetime of the peer entry is equal to the lifetime of the transport
connection. In case of a transport failure, all the pending transactions
destined to the unknown peer can be discarded."
--------------------------------------------------------------------------
Issue #305
--------------------------------------------------------------------------