Subject: DIAMETER Base Protocol (18-Alpha 1) draft / Identifier

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 17 Jan 2001 15:53:05 -0500

Hi Pat,

Dave Spence passed me some notes he had made some time back,
suggesting that the references the Identifier field could be
clarified.

Here is my take on Dave's suggestions:

- - -

Here's what Diameter-18 (Alpha 1) has to say:

  Identifier
    The Identifier field is four octets, and aids in matching
    requests and replies. The sender MUST ensure that the identifier
    in a message is locally unique (to the sender) at any given
    time, and MAY attempt to ensure that the number is unique across
    reboots. The identifier is normally a monotonically increasing
    number, whose start value was randomly generated. DIAMETER
    servers should consider a message to be unique by examining the
    source address, source port, Session-Id and Identifier field of
    the message.

Suggestion: Distinguish between the requirement for the Identifier 
field in request messages versus reply messages.

Discussion: The first sentence of Diameter-18 says that the
Identifier field aids in matching requests and replies.  The second
sentence says that the sender MUST ensure that the identifier in a
message is locally unique (to the sender).  But this second
statement only applies to requests.  It is incorrect for responses.
For responses, the Identifier should presumably be copied from the
Identifier field of the corresponding request.  That isn't stated
here, and not all of the specific response specifications state this
either.

Suggestion: Indicate that a proxy is required to manufacture his own
Identifier value when forwarding a request, and is required to
replace the originally received Identifier when returning a
response.

Discussion: As to the Identifier being unique with respect to the
sender, the fourth sentence of Diameter-18 clarifies that "sender"
means "source address and source port".  This implies that the proxy
should overwrite the value of the Identifier field when forwarding.  

Now that responses need to be returned back down the request path
but in reverse (NAI-based message routing by proxies was removed
between diameter-17 and diameter-18), having the proxies change the
Identifier field will help them match responses to requests.  State
stored in the proxy or in the Proxy-State AVP can be used to
correctly replace the Identifier field as the response is returned
back down the chain.  

All this mechanism should be specified in the protocol.

- - -

Historical note-- 

    draft-calhoun-diameter-17.txt gave routing proxies the option of
NAI-based message routing, which allowed a response to be returned
through a different path.  This meant that a routing proxy, when
forwarding a request, could not meet the requirements, whether he
overwrote the originally received Identifier or not. (!)

    When returning the response through a different proxy,
overwriting the value of the Identifier field by a proxy in the
Request path could result in cases where the NAS receives a response
whose Identifier does not match that sent in the NAS's request.

    Firstly, The overwritten Identifier field would not help the
proxy receiving the response at all, but presumably it doesn't
need to be helped because any state it needs will not be in its
memory but must be retrieved from the Proxy-State AVP (which
must have the format it expects).  

    Secondly, there may be more than one proxy in the chain, and
different numbers of proxies on the way out than on the way back.
Then the "send it back a different way" mechanism is broken.  There
is just no way to get the Identifier field right in the copy of the
response that gets sent to the NAS.  So in that case, the right
thing to do would have been for proxies not to change the Identifier
field.  But this violates the sender's unique-Identifier requirement.

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 19 Jan 2001 14:01:20 -0800 (PST)

> here, and not all of the specific response specifications state this

Correct, I will fix the text.

> All this mechanism should be specified in the protocol.

Yes, I do agree, and this text belongs somewhere in section 6, where proxying
is discussed.

> field.  But this violates the sender's unique-Identifier requirement.
yes, I agree that proxies would not be able to change the Identifier field if
the reverse path was different. Since this is no longer supported (to simplify
the protocol), this problem no longer exists.

Thanks to you and Dave for pointing this out.

PatC