Subject: Re: [Dime] Robert Sparks' Discuss on draft-ietf-dime-rfc3588bis-29: (with DISCUSS and COMMENT)

From: Glen Zorn <[email-masked]>
Date: Wed, 07 Mar 2012 15:03:28 +0700

On 9/21/2011 4:17 AM, Robert Sparks wrote:
> Robert Sparks has entered the following ballot position for
> draft-ietf-dime-rfc3588bis-29: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The document reflects the change of the name of the Well-Known
> IANA policy definition from "IETF Consensus" to "IETF Review", but
> seems to state that this is a change of policy rather than a change
> of the policy name (as explained in RFC5226).  Specifically, it says
> "now only require IETF Review as opposed to an IETF Consensus".
> Has the working group captured what it intended?

I don't think so; how about this:

OLD:
   AVPs may be allocated following Expert Review (or Designated Expert)
   with Specification Required [RFC5226].  As a change from RFC3588, a
   block allocation (release of more than 3 at a time for a given
   purpose) now only require IETF Review as opposed to an IETF Consensus
   in RFC3588.

NEW:
   AVPs may be allocated following Expert Review (or Designated Expert)
   with Specification Required [RFC5226].  A block allocation (release
   of more than 3 AVPs at a time for a given purpose) requires IETF
   Review.
> 
> This sentence in section 2.1 is not clear:
>    For TLS [RFC5246] and DTLS [RFC4347], a Diameter
>    node that initiate a connection prior to any message exchanges MUST
>    run on port [TBD].
> What was its intent? It could be misread to say that you cannot establish
> a connection on any other port than [TBD].

I'm not sure that that would be a mis-reading.

> 
> In the new text on dynamic agent discovery, Section 5.2 part 3 -
> should an element that's looked up SRV records as specified in this
> item follow all of the requirements in RFC 2782 if multiple SRV records
> are returned (in particular, following the balancing algorithm over
> records with the same Priority)? Shouldn't this section reference RFC 2782?

Makes sense to me.  How about this:

OLD:
   3.  If no NAPTR records are found, the requester directly queries for
       SRV records '_diameter._sctp'.realm, '_diameter._dtls'.realm,
       '_diameter._tcp'.realm and '_diameter._tls'.realm depending on
       the requesters network protocol capabilities.  If SRV records are
       found then the requester can perform address record query (A RR's
       and/or AAAA RR's) for the target hostname specified in the SRV
       records.  If no SRV records are found, the requester gives up.

NEW:
   3.  If no NAPTR records are found, the requester directly queries for
       one of the following SRV records: for Diameter over TCP, use
       "_diameter._tcp.realm"; for Diameter over TLS, use
       "_diameters._tcp.realm"; for Diameter over SCTP, use
       "_diameter._sctp.realm"; for Diameter over DTLS, use
       "_diameters._sctp.realm".  If SRV records are found then the
       requester can perform address record query (A RR's and/or AAAA
       RR's) for the target hostname specified in the SRV records
       following the rules given in Gulbrandsen, et al.  [RFC2782].  If
       no SRV records are found, the requester gives up.
> 
> In the new text on the Election Process, "lexicographically succeeds" needs
> additional description.

Not quite sure why: IIRC, the term was chosen because it precisely
states the desired operation and is well-understood (straight out of
Intro to CS, actually).

> 
> The note at the end of 6.1 is very ambiguous - does "this section" mean
> just 6.1, but not 6.1.1 through 6.1.9, or did it mean to include those
> subsections?  Either way, it leaves the requirements language very hard
> to follow.  Does this say certain implemenentations MAY ignore some MUSTs?
> If so, which ones?

Again, I'm having trouble seeing any ambiguity here: the word "this"
very specific and the phrase "this section", if present in a section,
seems only to denote that section, not any sections that might follow or
precede it.  Maybe cut down on the caffeine? ;-)

> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In section 1.3.1's second paragraph, starting the second sentence with
> "Typically," is likely to introduce confusion about the allocation policy.

How can it introduce confusion about allocation policy _in this
document_ when the whole paragraph is just suggesting policies for
_other documents_?

> Why is the word needed in this sentence?

Because it's not specifying a rule, it's just making a suggestion.

> 
> In section 2, 2nd to last paragraph before section 2.1: This edit (moving
> how tranparency is described) resulted in a sentence that says Diameter Relays
> and redirect agents MUST support all Diameter applications. Please consider
> touching it again to make it clearer that those elements MUST be transparent
> to the applications, and as a result trivially support them.

It's hard to see the difference.

> 
> In section 2.1, 3rd paragraph when discussing reverting to TCP or SCTP,
> please consider pointing out that section 2.2 still requires _SOME_ security
> mechanism be used.

The reason why the initiator reverts is that the peer only supports RFC
3588, which requires some security mechanism to be used.

> 
> The edits to the first paragraph of the description of AVP flags left
> the sentence "Unrecognized bits SHOULD be considered an error." unsupported.
> It's not clear (without looking at the diff to 3588) what bits might
> possibly be unrecognized.

I think that this is correct: any unrecognized bit would have to be one
of the 'r' bits it seems & a sender MUST set all the r' bits to 0 so
this can never happen (with a conformant implementation.  How about we
just remove that sentence?

> 
> In section 6.1.2, can the document say why the hop-by-hop identifier
> SHOULD be locally unique rather than MUST be?

I don't know; anybody?

> 
> 
> NITS:
> In section 1.3.1 paragraph 1, the reference to 11.4 should be 11.3.

Fixed.

> 
> Section 2.7 Realm Name: s/that is MUST/that MUST/

Fixed

> 
> Section 6.1.9: s/list of commonly recommended/list of common recommendations/
> 

Fixed.

> Something is wrong with this line in section 7.2
> (The line is unchanged from 3588, but if this is a bug, it should be
> addressed at some point). 
>       <answer-message> ::= < Diameter Header: code, ERR [PXY] >
> That has either one too many or one too few commas in it.

I think that this should read
<answer-message> ::= < Diameter Header: code, ERR [, PXY] >

> 
> The following is a pedantic nit, but please consider addressing it.
> In several places (both in text from 3588 and new text introduced as
> part of this effort), the text refers to the definitions of commands
> in the representational language defined in section 3.2 as ABNF. For
> example:
>    The Grouped Data field has the following ABNF grammar:
> 
>          Proxy-Info ::= < AVP Header: 284 >
>                         { Proxy-Host }
>                         { Proxy-State }
>                       * [ AVP ]
> 
> That is not ABNF. Instead, it is a well formed message in a language described
> by the ABNF in section 3.2. It would be better to say something like
> "The Grouped data field has the following Command Code specification:".

This particular pedantic nit seems very popular amongst the IESG ;-).  I
would like it very much if you folks could come to a consensus as to
whether it must be changed and, if so, how to change it.  TIA!

---

From: Glen Zorn <[email-masked]>
Date: Thu, 08 Mar 2012 10:01:00 +0700

On 3/8/2012 3:05 AM, Robert Sparks wrote:
> Thanks for the response Glen
> 
> Discussion inline.
> 

...

> If that's the case, consider saying "run only on port". But doesn't that
> interact badly
> with the peer discovery mechanism? Or are you saying it would be an
> error to create
> an SRV record that pointed to any port other than TBD?

Actually, I'm just not sure (I didn't write this part ;-).  I'm hoping
that somebody else will chime in...

...

> Rereading this after several months, I think it's fine. My point was you
> need to specify
> the lexicon. You did (case-insensitive ASCII - so you know "A2"<"AA").
> The way you
> point to Appendix D makes it seem that will affect ordering (it
> doesn't). Is there a place
> in the DNS specs you can point to that makes order comparisons explicit
> to remove
> all potential ambiguity?

Beats me; anybody?

> You didn't answer whether you believe 6.1.1 is part of, or follows, 6.1.

I think that 6.1.1 is not part of 6.1; the following subsection _do_
contain RFC 2119 language, while 6.1 doesn't, so I would expect that the
broad outline of processing in 6.1 is descriptive while the following
subsections are prescriptive.

> I don't know what potential confusion I saw at the time. I'll remove the
> comment,
> but consider changing "should" to "would" in that suggestion.

OK.

> A clarification would make it more obvious that "support" in this
> circumstance
> means simply "be transparent". Encourage the focus of the implementer
> towards
> being transparent to an abstract thing rather than making sure they
> "support"
> whatever the current list of defined applications is.

I think we may be talking about two different kinds of transparency.  I
don't think that redirect agents, in particular, can actually be
transparent to the endpoint nodes (since they actually return a message
telling where to send the original message) ; relays can probably be
transparent, but they need to recognize, at least, any Diameter message
that comes to them so that it can be forwarded correctly.

> It would hurt to point that out?

Just seems like beating a dying (if not dead) horse ;-)

> I think you still need it.
> 
> Note that subsequent Diameter applications MAY define additional bits
> within the AVP Header, and an unrecognized bit SHOULD be considered an
> error.
> 
> The 3588bis text says this now:
> New Diameter applications SHOULD NOT define
>       additional AVP Flag bits.  The sender of the AVP MUST set 'r'
>       (reserved) bits to 0 and the receiver SHOULD ignore all 'r'
>       (reserved) bits.  Unrecognized bits SHOULD be considered an error.
> 
> The new text still leaves the possibility for additional (unrecognized)
> AVP bits to show up,
> defined by new applications.
> 
> Maybe just swap the last two sentences in the new text?

OK

...

> Well, I put this in as a comment, not a blocking point.
> 
> I think changing it would make the document more correct, and the suggestion
> I make above would fix it and doesn't look too hard to implement. Am I
> missing something?

My point is that several IESG members have complained about this; I
don't mind fixing it, if necessary, but I only want to do it once.  Just
BTW, as I recall RFC 3588 was gone over with a fine-tooth comb by
various ABNF geeks before it was published; since neither the definition
of ABNF nor the actual "ABNF" in 3588bis has changed since then I find
it rather amazing that it has somehow become defective.

---

From: Glen Zorn <[email-masked]>
Date: Thu, 08 Mar 2012 12:19:38 +0700

On 3/8/2012 10:01 AM, Glen Zorn wrote:

...

>> Maybe just swap the last two sentences in the new text?

How' about this:

OLD:
   AVP Flags

      The AVP Flags field informs the receiver how each attribute must
      be handled.  New Diameter applications SHOULD NOT define
      additional AVP Flag bits.  The sender of the AVP MUST set 'r'
      (reserved) bits to 0 and the receiver SHOULD ignore all 'r'
      (reserved) bits.  Unrecognized bits SHOULD be considered an error.

NEW:
   AVP Flags

      The AVP Flags field informs the receiver how each attribute must
      be handled.  New Diameter applications SHOULD NOT define
      additional AVP Flag bits.  Note however, that new Diameter
      applications MAY define additional bits within the AVP Header, and
      an unrecognized bit SHOULD be considered an error.  The sender of
      the AVP MUST set 'r' (reserved) bits to 0 and the receiver SHOULD
      ignore all 'r' (reserved) bits.
...

---

From: Robert Sparks <[email-masked]>
Date: Thu, 08 Mar 2012 15:17:05 -0600

> that somebody else will chime in...
Who should be responding?

I think the right thing to do here is to change the MUST above to "by 
default" and note that
the SRV-based peer discovery mechanism may specify other ports.
> subsections are prescriptive.
And when I read it, I don't. This still looks like a loophole for people 
to avoid
implementing what the spec should be requiring. With these two sentences:

"   Note the processing rules contained in this section are intended to
    be used as general guidelines to Diameter developers.  Certain
    implementations MAY use different methods than the ones described
    here, and still comply with the protocol specification."

and implementer could totally ignore the MUSTs in section 6.1.3:

"6.1.3.  Receiving Requests

    A relay or proxy agent MUST check for forwarding loops when receiving
    requests.  A loop is detected if the server finds its own identity in
    a Route-Record AVP.  When such an event occurs, the agent MUST answer
    with the Result-Code AVP set to DIAMETER_LOOP_DETECTED."

and still claim to comply with the protocol specification.

Would the following work for you:

"The overview contained in this section (6.1) are intended to be
used as general guidelines to Diameter developers. Implementations
are free to use different methods than the ones described here as long
as they conform to the requirements in sections 6.1.1 through 6.1.9".

>> but consider changing "should" to "would" in that suggestion.
(just to make sure you left it on purpose - it's still should in 30).
> telling where to send the original message) ;
Sure, but the redirect mechanics are general, not application specific.
>   relays can probably be
Fair enough. The end goal is to make sure redirect agents and relays don't
necessarily have to be touched in order to deploy new applications. The
behavior I'm hoping most  to not encourage is a relay keeping a list of 
applications
that it checks each message against before forwarding it.

That said, I don't have text to propose, and you've done what I asked 
(which was to consider
a clarification). I'm willing to let this go.

> Just seems like beating a dying (if not dead) horse ;-)
Product managers look hard to find ways to push features off...
>>> of the 'r' bits it seems&  a sender MUST set all the r' bits to 0 so
Thanks for making that change - as I noted while updating my ballot, I 
think the MAY that got added hurts a little.
>>>>           Proxy-Info ::=<  AVP Header: 284>
>>>>                          { Proxy-Host }
>>>>                          { Proxy-State }
>>>>                        * [ AVP ]
>>>>
Well, let me see if I can pull the consensus you're looking for together 
quickly.

As far as I can tell, nobody's blocking this - they're just noting it's 
had an error for all this time and now
would be an easy time to fix it. The value returned for going through 
the pain will be making it less likely
that some other spec developer copies the error. (And maybe avoiding 
going through this same conversation
the next time this spec is revised).

---

From: Robert Sparks <[email-masked]>
Date: Thu, 08 Mar 2012 15:42:41 -0600

WG participants, and document reviewers:

Several folks have pointed out that 3588 misused the term ABNF in a few 
places, and the misuse was inherited by 3588bis.

The command code syntax itself is specified (correctly) using ABNF. 
Phrases like the section header for 3.2
"3.2 Command Code ABNF Specification"
are correct.

Sections that _use_ the command code grammar incorrectly call that ABNF. 
An example is section
4.4.1, where it says:

          Example-AVP  ::= < AVP Header: 999999 >
                           { Origin-Host }
                         1*{ Session-Id }
                          *[ AVP ]

That isn't ABNF, it's an expression in the command code grammar defined 
by the ABNF in section 3.2.
An ABNF parser would reject it if you provided it as input. A diameter 
command code syntax parser would
accept it.

This is a minor, pedantic, point, but several reviewers raised it (but 
none are asking to block the document
on changing it). There's an opportunity to clean it up now. The benefit 
would be a slight increase in correctness,
a decrease in the likelihood that someone would copy the mistake in a 
future specification, and avoiding
another set of comments like this one should RFC-to-be-3588bis should 
ever be revised.

Here's a concrete suggestion that I think is easy to implement and would 
satisfy all the review comments.

Would anyone object to changing the places where ABNF is misused to 
variants of "command code specification"?
For instance, the errant sentence in 4.4.1 would become "The Grouped 
Data field has the following command code specification". In section 
6.6, "An ABNF for a request message" would be come "The command code 
specification for a request message". And so on.

RjS

On 3/8/12 3:17 PM, Robert Sparks wrote:
> And when I read it, I don't. This still looks like a loophole for 
> people to avoid
> behavior I'm hoping most  to not encourage is a relay keeping a list 
> of applications
> Well, let me see if I can pull the consensus you're looking for 
> together quickly.
>
> As far as I can tell, nobody's blocking this - they're just noting 
> it's had an error for all this time and now

---

From: Jouni <[email-masked]>
Date: Fri, 9 Mar 2012 00:26:48 +0200

Robert,

On Mar 8, 2012, at 11:17 PM, Robert Sparks wrote:

> I think the right thing to do here is to change the MUST above to "by default" and note that

It actually looks fuzzy.. "run on port" intends to say that a Diameter node
must at least bind its listening socket to port [TBD]. When creating a connection
the source port can be other than [TBD] but should be the same [TBD]..

The wording does not actually allow listening for incoming connections on
other ports that 3868 and [TBD], which effectively puts a restriction on
the use of SRV.

>>> in the DNS specs you can point to that makes order comparisons explicit

Not me.

> And when I read it, I don't. This still looks like a loophole for people to avoid

Would work for me.

[snip]

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Fri, 09 Mar 2012 11:15:28 +0700

> the SRV-based peer discovery mechanism may specify other ports.

I'm gonna let the Chairs respond to this.

...

> and implementer could totally ignore the MUSTs in section 6.1.3:

Implementers can (and do!) do anything they want ;-)

> as they conform to the requirements in sections 6.1.1 through 6.1.9".

OK w/me.

> (just to make sure you left it on purpose - it's still should in 30).

Whoops!  Thank you.

> that it checks each message against before forwarding it.

Because Diameter messages are outed by app ID & realm, I'm not sure how
that can be avoided.

> a clarification). I'm willing to let this go.

OK, thanks.

> Product managers look hard to find ways to push features off...

One problem is that Diameter security requirements have been roundly
ignored by the community in favor of plugging their ears and going
"lalala" really loud ;-).  I don't see how changing this will change
that.  In any case, -31 says that "The Diameter protocol MUST NOT be
used without one of TLS, DTLS or IPsec." and this is repeated in the
Security Considerations section; note that it doesn't say anything
version-specific.

> think the MAY that got added hurts a little.

I would be inclined to make the "MAY" into a "may" or a "might", as in

      Note however, that new Diameter
      applications might define additional bits within the AVP Header;
      an unrecognized bit SHOULD be considered an error.

> Well, let me see if I can pull the consensus you're looking for together

Thanks!

---

From: Glen Zorn <[email-masked]>
Date: Fri, 09 Mar 2012 12:11:14 +0700

> other ports that 3868 and [TBD], which effectively puts a restriction on

OK, so how to change it?

...

>> as they conform to the requirements in sections 6.1.1 through 6.1.9".

OK, this is what I have now:

   The overview contained in this section (6.1) is intended to provide
   general guidelines to Diameter developers.  Implementations are free
   to use different methods than the ones described here as long as they
   conform to the requirements specified in Sections 6.1.1 through
   6.1.9.  See Section 7 for more detail on error handling.

...

---

From: Glen Zorn <[email-masked]>
Date: Fri, 09 Mar 2012 14:19:14 +0700

> variants of "command code specification"?

I would: there are at least 50 of those places in the draft and each
would require individualized wordsmithing.  If it really needs to be
changed, I would prefer to have an acronym with which I could just
globally replace "ABNF", saving hours of work.

...

---

From: jouni korhonen <[email-masked]>
Date: Fri, 9 Mar 2012 10:49:53 +0200

Glen, Robert, WG,

>> other ports that 3868 and [TBD], which effectively puts a restriction on

I looked back to old archives back to early 2000 and there John Loughney
said that NAPTR was introduced to allow flexibility on TLS ports i.e. not
only rely on fixed port numbers. So we probably then should make it clear
a DNS based peer discovery can override default ports. How about:

   ...

   The base Diameter protocol is run (i.e., listens for incoming connections)
   on port 3868 for both TCP [RFC793] and SCTP [RFC4960]. It is assumed that
   TLS [RFC5246] is run on top of TCP when it is used and DTLS [RFC6347] is
   run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port [TBD], i.e. the peer complies only with
   [RFC3588], then the initiator MAY revert to using TCP or SCTP and on
   port 3868.  Note that this scheme is kept for the purpose of
   backwards compatibility only and that there are inherent security
   vulnerabilities when the initial CER/CEA messages are sent un-
   protected (see Section 5.6).

   Diameter clients MUST support either TCP or SCTP, while agents and
   servers SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   MUST always be prepared to receive connections on port 3868 for TCP or
   SCTP and port [TBD] for TLS/TCP and DTLS/SCTP connections. When DNS-based
   peer discovery is used, the port numbers received from SRV records
   take precedence over default ports 3868 and [TBD].

Comments?

- Jouni

> <gwz.vcf>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 07 Mar 2012 14:05:13 -0600

Discussion inline.

> On 9/21/2011 4:17 AM, Robert Sparks wrote:
September. Ouch.  Swapping state back in...
OK
OK

>>        <answer-message>  ::=<  Diameter Header: code, ERR [PXY]>
> <answer-message>  ::=<  Diameter Header: code, ERR [, PXY]>
>

---

From: Glen Zorn <[email-masked]>
Date: Fri, 09 Mar 2012 18:33:44 +0700

>    take precedence over default ports 3868 and [TBD].

Fine with me.

...

---

From: Eric McMurry <[email-masked]>
Date: Fri, 9 Mar 2012 07:54:51 -0600

>>>> Thanks for the response Glen
[...]
>> a clarification). I'm willing to let this go.

The difference is wether the list of applications considered for routing is static or dynamic at compile time for a given implementation.  I think the push for language that included "transparent" was intended to suggest to implementors that the list of applications not be compiled in, which would result in compliance with the letter, but not the spirit of the current requirement language.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Mar 2012 08:49:37 -0500

...
> globally replace "ABNF", saving hours of work.

Fair enough.  How about this suggestion, then?

3588bis, section 3.2:
OLD
   Every Command Code defined MUST include a corresponding ABNF
   specification, which is used to define the AVPs that MUST or MAY be
   present when sending the message.  The following format is used in
   the definition:
NEW
   Every Command Code defined MUST include a corresponding
   Command Code Format (CCF) specification, which is used to define
   the AVPs that MUST or MAY be present when sending the message.
   The following ABNF specifies the CCF used in the definition:

>> specification for a request message". And so on.

Now that becomes this:

"The Grouped Data field has the following CCF grammar:"
"The CCF for a request message"

It's a LITTLE more than just replacing "ABNF" with "CCF", because you
may have to change "an" to "a" or "the", but it should be quite easy.
(I suppose we could call it "Augmented Command Code Format", and get
around even that.)  Any document that cites 3588bis can put CCF (with
a citation) into its terminology section, and use "CCF" as well.

Barry

---

From: Robert Sparks <[email-masked]>
Date: Fri, 09 Mar 2012 09:27:44 -0600

wfm

---

From: Robert Sparks <[email-masked]>
Date: Fri, 09 Mar 2012 09:28:24 -0600

Thanks Glen!

---

From: Glen Zorn <[email-masked]>
Date: Sat, 10 Mar 2012 23:11:53 +0700

> a citation) into its terminology section, and use "CCF" as well.

Much Better, thanks!

---

From: Glen Zorn <[email-masked]>
Date: Sun, 11 Mar 2012 15:16:50 +0700

>>    take precedence over default ports 3868 and [TBD].

This is what I have now:

OLD:
2.1.  Transport

   The Diameter Transport profile is defined in [RFC3539].

   The base Diameter protocol is run on port 3868 for both TCP [RFC793]
   and SCTP [RFC4960].  For TLS [RFC5246] and DTLS [RFC6347], a Diameter
   node that initiate a connection prior to any message exchanges MUST
   run on port [TBD].  It is assumed that TLS is run on top of TCP when
   it is used and DTLS is run on top of SCTP when it is used.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   MUST be prepared to receive connections on port 3868 for TCP or SCTP
   and port [TBD] for TLS/TCP and DTLS/SCTP connections.  A given
   Diameter instance of the peer state machine MUST NOT use more than
   one transport connection to communicate with a given peer, unless
   multiple instances exist on the peer in which case a separate
   connection per process is allowed.

NEW:
2.1.  Transport

   The Diameter Transport profile is defined in [RFC3539].

   The base Diameter protocol is run on port 3868 for both TCP [RFC793]
   and SCTP [RFC4960].  For TLS [RFC5246] and DTLS [RFC6347], a Diameter
   node that initiate a connection prior to any message exchanges MUST
   run on port [TBD].  It is assumed that TLS is run on top of TCP when
   it is used and DTLS is run on top of SCTP when it is used.

   If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP
   connections on port [TBD] (i.e., the peer complies only with
   [RFC3588]), then the initiator MAY revert to using TCP or SCTP on
   port 3868.  Note that this scheme is kept only for the purpose of
   backward compatibility and that there are inherent security
   vulnerabilities when the initial CER/CEA messages are sent
   unprotected (see Section 5.6).

   Diameter clients MUST support either TCP or SCTP; agents and servers
   SHOULD support both.

   A Diameter node MAY initiate connections from a source port other
   than the one that it declares it accepts incoming connections on, and
   MUST always be prepared to receive connections on port 3868 for TCP
   or SCTP and port [TBD] for TLS/TCP and DTLS/SCTP connections.  When
   DNS-based peer discovery (Section 5.2) is used, the port numbers
   received from SRV records take precedence over the default ports
   (3868 and [TBD]).

   A given Diameter instance of the peer state machine MUST NOT use more
   than one transport connection to communicate with a given peer,
   unless multiple instances exist on the peer in which case a separate
   connection per process is allowed.
> 
> ...
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime