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

["Keshab Upadhya" <[e-mail]>]

Hi Jouni,

Thank you.

This is for server peer (HSS) for local request processing and handling of unknown destination host in s6a.

If I understand correctly, a (s6a) request message lands with realm and app is supported by HSS but destination hostname is "unknown" and doesn't have routing details in peer routing table for given hostname, there will be an error (DIAMETER_UNABLE_TO_DELIVER ) returned based on RFC 6733 - 6.1 where clause of 6.1.4, 6.1.5 and 6.1.6 conditions are not fulfilled.

Kindly confirm.

Thank you.

-----Original Message-----
From: Jouni [mailto:[e-mail]] 
Sent: Wednesday, September 16, 2015 12:38 PM
To: Keshab Upadhya
Cc: ext [e-mail]; RFC Errata System; Benoit Claise; joel jaeggli; [e-mail] list
Subject: Re: [Technical Errata Reported] RFC6733 (4462)

Hi,

Section 6.1 does state DIAMETER_UNABLE_TO_DELIVER to which the request receiving process imho falls to. I am assuming your node you are talking about is an agent.

- Jouni




> On 15 Sep 2015, at 19:56, Keshab Upadhya <[e-mail]> wrote:
> 
> Hi Jouni,
> 
> Thank you for response.
> 
> Yes, return error looks like suitable option here as well however it's 
> not mentioned in RFC6733, 1.6.5 explicitly.
> 
> What will be recommended alteration and which section it will be applicable?
> Kindly advice.
> 
> -----Original Message-----
> From: Jouni Korhonen [mailto:[e-mail]]
> Sent: Wednesday, September 16, 2015 5:26 AM
> To: Keshab Upadhya; [e-mail]; 'RFC Errata System'; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [Technical Errata Reported] RFC6733 (4462)
> 
> 
> 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.