Re: [Dime] [Technical Errata Reported] RFC6733 (4462)

[Jouni Korhonen <[e-mail]>]

The proposed correction does not seem right. For routing to work all 
nodes within a realm must be peer, which in this case does not seem to 
hold. I would just return an error.

- Jouni





9/14/2015, 12:12 AM, Keshab Upadhya kirjoitti:
> Hi Lionel,
>
> Thank you for valuable feedback.
>
> I believe your understanding is inline and primarily what you've
> summarized below clarifies objectively, thank you.
>
> Confusion with below statement of 6.1.6, paragraph 2:
>
> "When a request is received that includes a *_realm_* and/or
> *_application_* that is *_not_* locally supported, the message is routed
> to the peer configured in the routing table (see Section 2.7)."
>
> As per above statement if realm is present and if application is not
> locally supported then below action will be taken place.
>
> “---- if not, route the request based on Realm/application (section 6.1.6)”
>
> What will happen if towards a server peer node where hostname is
> incorrect and application id with realm locally supported?
>
> Understanding from RFC - If we go with 6.1.4, such message shouldn’t be
> processed locally but if we go with 6.1.6 message looks like should be
> processed locally based on above given underlined statement, defines
> contradiction of 6.1.4 & 6.1.6.
>
> After giving a second though on specs in section 6.1.4, if following
> altered–
>
> *_Original -_*
>
> 6.1.4.  Processing Local Requests
>
>     A request is known to be for local consumption when one of the
>
>     following conditions occurs:
>
>     o  The Destination-Host AVP contains the local host's identity;
>
>     o *The Destination-Host AVP is not present, the Destination-Realm AVP*
>
> *      contains a realm the server is configured to process locally, and*
>
> *     the Diameter application is locally supported; or*
>
>     o  Both the Destination-Host and the Destination-Realm are not
>
>        present
>
> *_Altered -_*
>
> 6.1.4.  Processing Local Requests
>
>     A request is known to be for local consumption when one of the
>
>     following conditions occurs:
>
>     o  The Destination-Host AVP contains the local host's identity;
>
>     o *The Destination-Host AVP is not present _in local peer routing
> table_, the Destination-Realm AVP*
>
> *      contains a realm the server is configured to process locally, and*
>
> *     the Diameter application is locally supported; or*
>
>     o  Both the Destination-Host and the Destination-Realm are not
>
>        present
>
> It will eliminate the contradiction.
>
> Please help enlighten us on this.
>
> Thank you,
>
> Keshab.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, September 10, 2015 11:15 PM
> To: Keshab Upadhya; 'RFC Errata System'; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Technical Errata Reported] RFC6733 (4462)
>
> Hi Keshab,
>
> I'm not totally sure to understand your concern.
>
> The purpose of the section 6.1.4 is to give the conditions for
> processing locally a request (i.e. how to know that the receiving entity
> is the one that needs to answer to the request?) and nothing else.
>
> The case you are referring to is covered in the section 6.1.6 and should
> not be part of section 6.1.4.
>
> To make a long story short...
>
> if the Destination-Host is present,
>
> - if the identity is equal to the local host's identity --> process
> locally (section 6.1.4)
>
> - if the identity is not equal to the local host's identity, check the
> peer table.
>
> ---- If it is the peer table, forward the request to the peer (sect 6.1.5)
>
> ---- if not, route the request based on Realm/application (section 6.1.6)
>
> Let me know if it is OK for you.
>
> Lionel
>
> -----Message d'origine-----
>
> De : Keshab Upadhya [mailto:[e-mail]] Envoyé : jeudi 10
> septembre 2015 05:26 À : 'RFC Errata System'; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
> [e-mail] <mailto:[e-mail]>; MORAND Lionel
> IMT/OLN Cc : [e-mail] <mailto:[e-mail]> Objet : RE: [Technical
> Errata Reported] RFC6733 (4462)
>
> Hi All,
>
> Good day!
>
> Could you please help on below request raised as conflict in RFC-6733?
>
> Kindly consider this as an urgent request.
>
> Thank you,
>
> Regards,
>
> Keshab.
>
> -----Original Message-----
>
> From: RFC Errata System [mailto:[e-mail]]
>
> Sent: Wednesday, September 2, 2015 9:09 AM
>
> To: [e-mail] <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>;
> [e-mail] <mailto:[e-mail]>;
> [e-mail] <mailto:[e-mail]>
>
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>; [e-mail]
> <mailto:[e-mail]>
>
> Subject: [Technical Errata Reported] RFC6733 (4462)
>
> The following errata report has been submitted for RFC6733, "Diameter
> Base Protocol".
>
> --------------------------------------
>
> You may review the report below and at:
>
> http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4462
>
> --------------------------------------
>
> Type: Technical
>
> Reported by: Keshab Upadhya <[e-mail] <mailto:[e-mail]>>
>
> Section: 6.1.4 6.1.6
>
> Original Text
>
> -------------
>
> 6.1.4.  Processing Local Requests
>
>     A request is known to be for local consumption when one of the
>
>     following conditions occurs:
>
>     o  The Destination-Host AVP contains the local host's identity;
>
>     o  The Destination-Host AVP is not present, the Destination-Realm AVP
>
>        contains a realm the server is configured to process locally, and
>
>       the Diameter application is locally supported; or
>
>     o  Both the Destination-Host and the Destination-Realm are not
>
>        present.
>
> 6.1.6.  Request Routing
>
>     Diameter request message routing is done via realms and Application
>
>     Ids. A Diameter message that may be forwarded by Diameter agents
>
>     (proxies, redirect agents, or relay agents) MUST include the target
>
>     realm in the Destination-Realm AVP.  Request routing SHOULD rely on
>
>     the Destination-Realm AVP and the Application Id present in the
>
>     request message header to aid in the routing decision.  The realm MAY
>
>     be retrieved from the User-Name AVP, which is in the form of a
>
>     Network Access Identifier (NAI).  The realm portion of the NAI is
>
>     inserted in the Destination-Realm AVP.
>
>     Diameter agents MAY have a list of locally supported realms and
>
>     applications, and they MAY have a list of externally supported realms
>
>     and applications.  When a request is received that includes a realm
>
>     and/or application that is not locally supported, the message is
>
>     routed to the peer configured in the routing table (see Section 2.7).
>
>     Realm names and Application Ids are the minimum supported routing
>
>     criteria, additional information may be needed to support redirect
>
>     semantics.
>
> Corrected Text
>
> --------------
>
> 6.1.6 -
>
>    When a request is received that includes a realm
>
>     and/or application that is not locally supported, the message is
>
>     routed to the peer configured
>
> conflicts with 6.1.4 -
>
>     The Destination-Host AVP is not present, the Destination-Realm AVP
>
>        contains a realm the server is configured to process locally, and
>
>        the Diameter application is locally supported
>
> Notes
>
> -----
>
> please guide if 6.1.4 Local processing - "hostname not present" needs to
> be amended by "not present in host peer routing table". otherwise it
> conflicts with 6.1.6.
>
> Instructions:
>
> -------------
>
> This erratum is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party (IESG) can log in to change the
> status and edit the report, if necessary.
>
> --------------------------------------
>
> RFC6733 (draft-ietf-dime-rfc3588bis-33)
>
> --------------------------------------
>
> Title               : Diameter Base Protocol
>
> Publication Date    : October 2012
>
> Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
>
> Category            : PROPOSED STANDARD
>
> Source              : Diameter Maintenance and Extensions
>
> Area                : Operations and Management
>
> Stream              : IETF
>
> Verifying Party     : IESG
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message par
> erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
> pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
>
> Thank you.
>