Interoperability and deployment issues for Diameter ERP.
Author: s.decugis

I - Peer and authenticator considerations.

This draft document considers all possible situations between the peer and the authenticator, 
with regards to ERP and feature supported on each entity.
It is based on my understanding of ERP mechanism, which is not complete, so if you see big mistakes 
please let me know.
In the first section, I detail the different situations that can occur for interoperability issues.
In the second section, I explain the sequence of events that are expected to occur in the different
combinations of situations.
In the third section, I give my views on what needs to be changed in the design so that some of the
problems detailed here will be avoided.
A separate document will be written later for: II - The backend considerations (interactions between ERP and EAP)


1. The variables.

1.1. Peer.

a. ERP support.

The peer may or may not support the ERP feature.
Support means being able to derive a rRK and rIK material from a EMSK, 
or from a DSRK derived from the EMSK and local domain name.
Support means also ability to send and receive ERP messages (new EAP codes).

Notation: 
A1 = The peer supports ERP feature. 
A2 = The peer does not support these features.


b. Availability of keying material.

When the peer supports the ERP feature, it must also have available 
keying material, i.e. valid EMSK, to use the feature.

Notation:
B1 = The peer has a valid EMSK from a previous EAP authentication.
B2 = The peer doesn't have such material available.


1.2. Authenticator.

a. ERP support.

An authenticator that does not support ERP feature is supposed to drop all
ERP packets. The support of ERP feature means that the authenticator is able
to extract the keyName-NAI from ERP message to help routing the Diameter message.

In some cases, the authenticator may also understand ERP messages but have determined
that no backend is available (configuration, capability exchange, other...) to perform
ERP operations and therefore simply reply errors to ERP messages from the peer. The 
benefit of this situation is that the peer does not have to retransmit and timeout the
ERP messages. On a functional point of view, this is equivalent to the case where the
peer does not support ERP.

Notation:
C1 = The authenticator supports ERP features.
C2 = The authenticator does not support ERP features or always sends Failure error codes.


b. Local domain name publication.

With some lower layers, the local domain name can be advertized to the peer
during discovery phase, while some other LL do not allow this.

It is always possible to advertise the local domain name in the EAP-Initiate/Re-auth-Start
packet as a TLV, but the peer may initiate EAP-Initiate/Re-auth exchange previously to receiving
the packet. Both situation have the same effect (peer not knowing the local domain name).

We must consider both situations.

Notation:
D1 = The authenticator advertises the local domain name through the LL or Re-Auth-Start ERP message
D2 = The peer does not receive this name.



2. Sequence of events.

This section is an attempt to describe the sequence of events that will occur when
a peer attaches to a new authenticator, in order to highlight the requirements and
possible issues for the ERP backend.

Reminder: the first step is the discovery phase. During this phase, the peer and authenticator 
may exchange information such as: ERP support, local domain name, who will start the exchange, ...
Then the EAP or ERP exchange occurs. It may take several echanges of messages. When
terminated, either the (re)authentication fails, or keying material (r)MSK is available to both
the peer and the authenticator. In the later case, a Security Association Protocol is initiated 
and uses the keying material to establish a protected connection to the network for the peer.

The following cases are considered in this section:
         --- authenticator ---
         |   C1    |    C2   |
         | D1 | D2 |  D1/D2  |
 |---------------------------|
 | A1 B1 |  1 |  2 |         |
 p-----------------|    5    |
 e A1 B2 |    3    |         |
 e---------------------------|
 r   A2  |         4         |
 | B1/B2 |                   |
 |---------------------------- 


2.1. A1, B1, C1, D1 - all conditions OK for ERP.

The peer receives the domain name from the new authenticator, and has a valid EMSK available.
It may also receive a EAP-Initiate/Re-auth-Start packet from the authenticator. If domain name
was not received during discovery phase, the peer should wait for the EAP-Initiate/Re-auth-Start
message to check if it contains the domain name.

Thanks to the domain name received from the authenticator, the peer can determine 
if it is attaching to its home domain or a foreign domain.

The peer must determine whether to start a bootstrapping ERP exchange or a normal ERP exchange.

In the case where the peer is in its home domain, bootstrapping or normal exchanges are equivalent.
(which one should be started?)

In the case where the peer is in a visited domain, a normal exchange will succeed only if the local
ER server possesses the DSRK material corresponding to the EMSK for this session of this peer.
This happens when:
- a previous ERP bootstrapping exchange already occurred in this domain.
- a full EAP authentication occurred in this domain, and implicit bootstrapping was used 
 (how does the peer know???)
- Alternatively, is it possible for the local ER server to request material from home ER server 
  if it does not have the required DSRK? 
  
If the peer determines that a bootstrapping exchange is started, it uses the rIK derived from the EMSK to 
protect the ERP message, and the keyName-NAI is EMSKname@homedomain. The local ER server adds a
ERP-DSRK-Request AVP while forwarding to the home ER server. The home ER server answers and adds the DSRK
(for the local ER server), the DS-rMSK (for the authenticator) and the domain name in the ERP message for the peer.
The peer uses this domain name to compute DSRK, DS-rRK and DS-rMSK.

If one of the conditions listed previously is matched, the peer may start a normal ERP exchange. In that case,
the keyName-NAI is EMSKname@localdomain. The message is protected by the DS-rIK. The local ER server receives this
request and provides a DS-rMSK to the authenticator.


2.2. A1, B1, C1, D2 - The peer does not receive the local domain name.

In this case, the peer will start an exchange with its home server. It may (should?) include the 'B' flag
(indicating bootstrapping exchange) to discover the local domain name if any.


2.3. A1, B2, C1 - No valid EMSK available to the peer.

In this case, a full EAP authentication is started. If the peer receives a EAP-Initiate/Re-auth-Start
from the authenticator, it ignores it and waits for a Request/Identity (how to avoid this 
delay ??? not clear in ERP document).

In the case where local domain name is received (D1), the peer can assume that this local domain
have a DSRK available for further re-authentication, making the assumption that ERP implicit bootstrapping was used.

What if no local ER server is available? The authenticator must not advertise the local domain? 


2.4. A2 - The peer does not support ERP.

In that case, the peer drops EAP-Initiate/Re-auth-Start packet if any and always uses full EAP authentication.
Initiating ERP implicit bootstrapping in that case is just a waste of computational power (and energy)
on the ER local and home servers. 

It is not important to know what features are supported by the authenticator in that case.

FFS: how to avoid implicit bootstrapping in that case? (to be "green")


2.5. A1, C2 - Authenticator (or backend) does not support ERP.

Any ERP message from the peer will be dropped or answered with failure code by the authenticator.
As a result the peer's EAP-Initiate/Re-auth will fail and the peer should fall back to using 
full EAP authentication.

If there is a local ER server, it may start implicit bootstrapping. Note that it will re-do 
implicit bootstrapping everytime the peer re-authenticates, using full EAP authentication each time.

We have the same problem as in 2.3, the peer can not know when no local ER server is available, and therefore
can not rely on implicit bootstrapping without more information.



3. Conclusion.

My conclusions with regards to the considerations from this document are as follow:

- The peer should always wait for first message from the authenticator if it does not receive domain name from LL, 
and the authenticator should always send a EAP-Initiate/Re-auth-Start message with domain-name TLV.

Pro: no dependency on lower layer to provide local domain name to the peer
Pro: reduces the number of possible situations to handle on the peer and authenticator.


- The peer must choose between initiating normal or bootstrapping ERP exchange. We restrict normal exchanges
to occur only after previous bootstrapping exchange in the same domain, that resulted in reception 
of the domain name (proof that the home ER server has sent the DSRK to a local ER server) i.e. we do never rely
on implicit bootstrapping.

Pro: the peer can decide whether to do normal or bootstrapping ERP.
Pro: no useless key derivation computation.
Pro: allow to use different Diameter Application ID for ERP, elimitating all current constraints on Diameter routing (FFS).
Pro: allow more flexibility in deployment scenario.
Con: need to re-design the Diameter ERP almost from scratch (but currently it can't work anyway...)
Con: one additional round-trip with home domain in the worst case.