Subject: [Dime] Several rfc 3588 issues.

From: Ralph Loader <[email-masked]>
Date: Wed, 11 Jul 2007 08:59:11 +1200

Hi,

Following is a list of issues I've come across in rfc3588.

I think all are current in the 3588bis-05 draft.

Many are cases where taking the text at face value does not match what
appears to be intended.  A few actually concern how the protocol operates.

Apologies for any due to me not RTFM well enough.

Cheers,
Ralph.

1.

'Home Server' in section 1.3, is defined with 'See Diameter
Server'.  But looking at the definition of 'Diameter Server', I
do not see any indication of what a 'Home Server' is.

Is the intention that 'Home Server' is a synonym for 'Diameter
Server', or is there some other meaning?  (E.g., a 'Diameter
Server' serving a 'Home Realm').

2.

If multiple Inband-Security-Ids are shared in the CER/CEA
exchange, the spec does not say how to choose which one to use.

3.

"minimum required length" in DIAMETER_INVALID_AVP_LENGTH (or
DIAMETER_MISSING_AVP) has several possible interpretations:
Minimum required for the basic datatype?  Minimum required for
the derived datatype?  Minimum required for successful
processing?

If it's minimum required for the datatype, and the datatype is
Grouped, is the minimum length the minimum for any grouped AVP
(i.e., empty payload) or the minimum for this particular AVP (in
which case zero-filling may generate a corrupt AVP)?

4.

Re DIAMETER_INVALID_AVP_LENGTH again, if the length received is
less than 12 but the AVP is vendor-specific, what should be put
in the Vendor-Id when creating the Failed-AVP?

5.

The <answer-message> (defined under 7.2. Error Bit) has just
[Proxy-Info] whereas everything else has *[Proxy-Info].
Presumably, *[Proxy-Info] is intended.

Also, <answer-message> ironically does not include
[Error-Message], and [Failed-AVP], unlike all other answers.

Although the inclusion of *[AVP] makes their omission formally
harmless, it would seem sensible to include them.

6.

The Vendor-Specific-Application-Id definition in
rfc3588bis-draft-05 does not use the grammar that according to
that document MUST be used.

Assuming that the intention is that one and only one of
Auth-Application-Id or Acct-Application-Id is present, the best
thing to do would be to make both optional in the grammar and
include the additional constraint in the text that exactly one MUST be
present.

7.

I don't think that the text

   "AVPs may be added arbitrarily to Diameter messages, so long
    as the required AVPs are included and AVPs that are
    explicitly excluded are not included."

is really what is intended.

I assume that the absense of *[AVP] in a message definition
means that unlisted AVPs may not be added arbitrarily to that
message, but I can see no text by which that is 'explicitly excluded'.

The current text makes the presence or absence of *[AVP] in a
message definition meaningless.

8.

Even ignoring the previous item, the meaning of *[AVP] (or
*{AVP}) in a message (or grouped-avp) format definition is
unclear, and RFC 3588 contradicts itself.

The description in 3.2 is

                       ; The string "AVP" stands for *any* arbitrary
                       ; AVP Name, which does not conflict with the
                       ; required or fixed position AVPs defined in
                       ; the command code definition.

According to this wording e.g., (a) Product-Name is allowed in
Abort-Session-Request, (b) multiple occurrences of User-Name are
allowed in Abort-Session-Request.  Both of these are
contradicted in section 10.

Taking section 10 a face value: (a) Product-Name must not occur
in an Abort-Session-Request, according to section 10, despite
the presence of *[AVP] in the message format, and (b) User-Name
must occur at most once in an ASR.

My guess as to the actual intent of the spec, is that:

         The string "AVP" stands for *any* arbitrary AVP Name,
         not otherwise listed in that command code grammar.

[This allows case (a) above but not case (b)]

The wording of section 10 then needs adjustment, to note that it
does not cover AVPs allowed because of *[AVP] in the grammar.

It would also make sense to me to remove all MUSTs/MAYs from
section 10, and instead to state that it is a non-normative
summary of what is implied in the command code definitions.

9.

The section 10 table lists Result-Code as not being present in
ASA, contradicting the definition of that command.

10.

The section 10 wording

    "Note that AVPs that can only be present within a Grouped AVP
    are not represented in this table"

is imprecise.  E.g., it could be taken to cover User-Name within
a Failed-AVP, on the grounds that it is not the case that
User-Name "can only be present within a Grouped AVP".

A better wording would be "Note that AVPs occurrences contained
within a Grouped AVP are not represented in this table".

11.

If a TCP connection is established with a 4-way handshake (i.e.,
both ends send SYNs simultaneously), then both ends will think
they are the initiator for CER/CEA exchange, and the exchange
then fails.  Is it intended to not allow this?  The wording

      A Diameter node MAY initiate connections from a source port
      other than the one that it declares it accepts incoming
      connections on, and

strongly suggests that also a node may initiate connections with the
source port being the one on which it accepts incoming
connections (i.e., 3868), in which case 4-way TCP handshake is a
realistic possibility.

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Rajith R <[email-masked]>
Date: Wed, 11 Jul 2007 11:09:48 +0530

>4.
>
>Re DIAMETER_INVALID_AVP_LENGTH again, if the length received 
>is less than 12 but the AVP is vendor-specific, what should be 
>put in the Vendor-Id when creating the Failed-AVP?

In this case, how could we determine the "minimum required length"? Since we
don't have the complete vendor Id, we will not know the type of the AVP.

>-----Original Message-----
>From: Ralph Loader [mailto:[email-masked]] 
>Sent: Wednesday, July 11, 2007 2:29 AM
>To: [email-masked]
>Subject: [Dime] Several rfc 3588 issues.
>
>Hi,
>
>Many are cases where taking the text at face value does not 
>match what appears to be intended.  A few actually concern how 
>the protocol operates.
>
>Server'.  But looking at the definition of 'Diameter Server', 
>I do not see any indication of what a 'Home Server' is.
>
>the derived datatype?  Minimum required for successful processing?
>
>(i.e., empty payload) or the minimum for this particular AVP 
>(in which case zero-filling may generate a corrupt AVP)?
>
>
>4.
>
>Re DIAMETER_INVALID_AVP_LENGTH again, if the length received 
>is less than 12 but the AVP is vendor-specific, what should be 
>put in the Vendor-Id when creating the Failed-AVP?
>
>
>5.
>
>Auth-Application-Id or Acct-Application-Id is present, the 
>best thing to do would be to make both optional in the grammar 
>and include the additional constraint in the text that exactly 
>one MUST be present.
>
>
>7.
>
>Abort-Session-Request, (b) multiple occurrences of User-Name 
>are allowed in Abort-Session-Request.  Both of these are 
>Taking section 10 a face value: (a) Product-Name must not 
>occur in an Abort-Session-Request, according to section 10, 
>despite the presence of *[AVP] in the message format, and (b) 
>User-Name must occur at most once in an ASR.
>
>The wording of section 10 then needs adjustment, to note that 
>it does not cover AVPs allowed because of *[AVP] in the grammar.
>
>is imprecise.  E.g., it could be taken to cover User-Name 
>within a Failed-AVP, on the grounds that it is not the case 
>that User-Name "can only be present within a Grouped AVP".
>
>A better wording would be "Note that AVPs occurrences 
>contained within a Grouped AVP are not represented in this table".
>
>
>11.
>
>If a TCP connection is established with a 4-way handshake 
>(i.e., both ends send SYNs simultaneously), then both ends 
>will think they are the initiator for CER/CEA exchange, and 
>the exchange then fails.  Is it intended to not allow this?  
>The wording
>
>strongly suggests that also a node may initiate connections 
>with the source port being the one on which it accepts 
>incoming connections (i.e., 3868), in which case 4-way TCP 
>handshake is a realistic possibility.
>
>

---

From: [email-masked]
Date: Wed, 11 Jul 2007 19:08:05 +1200 (NZST)

> don't have the complete vendor Id, we will not know the type of the AVP.

Good point.

How about adding the following to the description of
DIAMETER_INVALID_AVP_LENGTH, immediately after the current draft-05 text:

"In the cases where the offending AVP code (or vendor id) is unknown to
the peer, the payload [of the AVP included in the Failed-AVP] may be
empty. In the cases where the offending AVP has the V-bit set but does not
contain a complete vendor id, the vendor id included inside the Failed-AVP
may be set to zero."

Does that cover the required cases?

R.

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 11 Jul 2007 09:24:10 -0400

Hi Ralph,

Thanks for the good review. Comments inline:

> Server' serving a 'Home Realm'). how about we use empty payload ?
>

Yes its suppose to be a synonym. Though I'm not sure what you mean by 
empty payload. If you want we can just say:

"A Diameter Server which serves the Home Realm".

> exchange, the spec does not say how to choose which one to use.

I'm guessing it co-relates with Host-IP-Address when using TLS over 
several bi-directional streams in SCTP (rfc3436). I hope others can 
verify this and we can add clarifying text.

> the derived datatype?  Minimum required for successful

Its suppose to be the former - derived datatype. We can add text based 
on both scenarios and your comments below to describe what "minimum req 
length" means.

> which case zero-filling may generate a corrupt AVP)?

For simplicity (and to make sense), we can just use a grouped AVP with 
an empty payload.

> Presumably, *[Proxy-Info] is intended.

Ok. We should probably also note in 7.2 that e-bit answer messages can 
be sent for permanent errors as well.

> harmless, it would seem sensible to include them.

Make sense, this was probably missed when we allowed permanent failures 
to be sent with e-bit answer messages.

> include the additional constraint in the text that exactly one MUST be

Mmmm ... I think that was the original grammar (as well as text) and 
people where confused about that also. The new grammar:

      <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                           { Vendor-Id }
                                           { Auth-Application-Id } /
                                           { Acct-Application-Id }

has them as OR (Note the "/" after auth-app-id). I'm assuming thats the 
correct ABNF representation for OR. Maybe some grouping is needed 
(rfc4234), like:

      <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                           { Vendor-Id }
                                         ( { Auth-Application-Id } /
                                           { Acct-Application-Id } )

> message definition meaningless.

make sense. How about re-wording from:

"AVPs may be added arbitrarily to Diameter messages,
 so long as the required AVPs are included and AVPs that are
 explicitly excluded are not included."

to:

"AVPs may be added arbitrarily to Diameter messages,
  so long as the requirements of a messages ABNF are
  met and the ABNF allows for it."

> [This allows case (a) above but not case (b)]

Yes this was the intent. Luckily most folks understood it that way or 
ignored the text :). We can re-word based on your suggestion. If we do 
so, would'nt a commands ABNF already cover (b) ?

> summary of what is implied in the command code definitions.

Not sure if that will make the table any more readable. Some of those 
MUST/MAY sentences describes how to read the table.

> ASA, contradicting the definition of that command.

Ok.

> within a Grouped AVP are not represented in this table".

Ok. Though both sentence look similar. Can we make it plain and simple: 
"AVPs that occur only inside a Grouped AVP are not shown in this table".

> connections (i.e., 3868), in which case 4-way TCP handshake is a

The "MAY" in the statement above does not restrict you from using source 
port 3868. Is this still a problem ?

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 11 Jul 2007 12:15:46 -0400

Hi folks,
> Does that cover the required cases?

Just to summarize the cases for INVALID_AVP_LENGTH:

a. length >= 12: the receiver can probably decode the header since it 
can tell whether the length field is incorrect in the first place. In 
this the existing scheme works. If it cannot decode the AVP (corruption) 
then this falls under (b).
b. length < 12: Likely possibility that the AVP header cannot be 
decoded. This is regardless and whether the AVP is vendor specific or 
not, or whether initial portions of the header are still parsable. In 
this case, I would suggest doing a best-effort, catch-all scheme where 
the reporter of the error sends the set of offending octects with 
additional padding for a total of 12-octets (header size). It is 
preferable if avoid specifying special conditions for corner case 
scenarios that adds very little value. Comments ?

best regards,
victor

---

From: "harish raghuveer" <[email-masked]>
Date: Wed, 11 Jul 2007 22:17:46 +0530

Hi all,

I have a couple of points/questions regarding Issue #11.

If there is a TCP connection establishment collision, wont
the election process decide who would be the initiator and who would
be the responder and break the tie?

Consider two peers A and B, both trying to set up TCP connection
simultaneously.
Both receive the CER, but the election process would have put one of
the node in responder state and the other in initiator state. The
CER received at the (elected) initiator side would be dropped ideally and
connection closed .

Isnt the statemachine handling this collision scenario currently?

Or did I get Ralph incorrectly?

thanks,
Harish

-- 
Harish R Prabhu
Bangalore, India.

---

From: "Thomas Lindgren" <[email-masked]>
Date: Wed, 11 Jul 2007 19:19:54 +0200

> scenarios that adds very little value. Comments ?

Here is a suggestion: One simple, straightforward approach is to define
Failed-AVP to have the type OctetString instead of 1*{AVP}. This approach
means there is no need for special cases when the bad AVP is malformed.
Instead, when there is an error just wrap the offending data and let the
originator figure out what went wrong when the reply arrives (using
Failed-AVP, Result-Code, Error-Message and so on).

Note that it might furthermore be _nice_ to cleanly separate multiple AVPs
in the Failed-AVP body, but it's not strictly necessary as far as I can
tell: instead, as part of error processing just try to decode the
OctetString contents as one or more AVPs. The code for doing that would
basically be the same as for decoding the current Failed-AVP.

Best,
Thomas
--
Thomas Lindgren, Millpond Services Ltd
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 11 Jul 2007 13:37:32 -0400

Hi Thomas,

Comments inline:

> Here is a suggestion: One simple, straightforward approach is to 
> define Failed-AVP to have the type OctetString instead of 1*{AVP}. 
> This approach means there is no need for special cases when the bad 
> AVP is malformed. Instead, when there is an error just wrap the 
> offending data and let the originator figure out what went wrong when 
> the reply arrives (using Failed-AVP, Result-Code, Error-Message and so 
> on).

Theoretically, its straightforward. Though what would happen to errors 
like contradicting AVPs, invalid avp values etc. Failed-AVP was designed 
to indicate which is the offending avps in these cases. Another issue 
maybe is backward compatibility with existing implementation (if people 
care about it). Maybe the octetstring scheme can be useful for malformed 
AVPs/messages only ...

-- victor

---

From: Ralph Loader <[email-masked]>
Date: Thu, 12 Jul 2007 09:26:15 +1200

Victor Fajardo wrote:
> empty payload.

Looks like I hit the paste key by accident...

> has them as OR (Note the "/" after auth-app-id). I'm assuming thats the 

This use of "/" is not described in the rfc3588 section 3.2 and section 
4.4 description of the grammars.

The phrasing:

    Every Grouped AVP defined MUST include a corresponding grammar,
    using ABNF [RFC4234] (with modifications), as defined below.

seems to make it clear that the section 4.4 grammar, not RFC4234, is 
normative.

The use of "/" could be added to section 4.4, although it would seem 
preferable to me to treat the exceptional case ad. hoc.

>  met and the ABNF allows for it."

Much clearer.  "message's ABNF" if I'm getting apostrophes correct today.