Subject: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (4931)

From: Benoit Claise <[email-masked]>
Date: Thu, 9 Feb 2017 10:52:20 +0100

AAA doctors,

What do you think of this errata?

Regards, B.

-------- Forwarded Message --------
Subject: 	[Technical Errata Reported] RFC6733 (4931)
Date: 	Wed, 8 Feb 2017 18:56:34 -0800
From: 	RFC Errata System <[email-masked]>
To: 	[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]
CC: 	[email-masked], [email-masked], text/[email-masked], 
charset=[email-masked]

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=4931

--------------------------------------
Type: Technical
Reported by: Luiz Solis <[email-masked]>

Section: 6.1.9

Original Text
-------------
Figure 6.1 provides an example of message routing using the procedures
listed in these sections.

(Origin-Host=nas.example.net)    (Origin-Host=nas.example.net)
(Origin-Realm=example.net)       (Origin-Realm=example.net)
(Destination-Realm=example.com)  (Destination-Realm=example.com)
                                  (Route-Record=nas.example.net)

+------+      ------>      +------+      ------>      +------+
|      |     (Request)     |      |      (Request)    |      |
| NAS  +-------------------+ DRL  +-------------------+ HMS  |
|      |                   |      |                   |      |
+------+     <------       +------+     <------       +------+
example.net    (Answer)   example.net     (Answer)   example.com
(Origin-Host=hms.example.com)   (Origin-Host=hms.example.com)
(Origin-Realm=example.com)      (Origin-Realm=example.com)

        Figure 6: Routing of Diameter messages

Corrected Text
--------------
Figure 6.1 provides an example of message routing using the procedures
listed in these sections.

(Origin-Host=nas.example.net)    (Origin-Host=nas.example.net)
(Origin-Realm=example.net)       (Origin-Realm=example.net)
(Destination-Realm=example.com)  (Destination-Realm=example.com)
(Route-Record=nas.example.net)*  (Route-Record=nas.example.net)
                                  (Route-Record=drl.example.net)*
+------+      ------>      +------+      ------>      +------+
|      |     (Request)     |      |      (Request)    |      |
| NAS  +-------------------+ DRL  +-------------------+ HMS  |
|      |                   |      |                   |      |
+------+     <------       +------+     <------       +------+
example.net    (Answer)   example.net     (Answer)   example.com
(Origin-Host=hms.example.com)   (Origin-Host=hms.example.com)
(Origin-Realm=example.com)      (Origin-Realm=example.com)

*Optional.

                   Figure 6: Routing of Diameter messages

Notes
-----
The relay or proxy agent should append their own identity optionally in an additional Route-Record AVP (282).

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
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
.

---

From: Jouni <[email-masked]>
Date: Thu, 9 Feb 2017 13:30:56 -0800

RFC6733 Sections 2.9 and 6.1.9 are rather clear that a relay and a proxy MUST append a Route-Record to all requests forwarded with the identity of the peer from which the request was received. There is no text that a relay or a proxy should add its own identity. If the agent were to add its own identity it would result duplicate entries of Route-Records if there are more than one agent on the path. Additionally an agent adding its own identity to a Route-Record seems to go against a MUST Section 6.7.1.

This errata should be rejected.

- Jouni

> On 09 Feb 2017, at 01:52, Benoit Claise <[email-masked]> wrote:
> 
> AAA doctors,
> 
> To:	[email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> CC:	[email-masked], [email-masked], text/[email-masked], charset=[email-masked]
> 
> _______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: <[email-masked]>
Date: Fri, 10 Feb 2017 00:33:02 +0000

The Route-Record is primarily used to detect loops:

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.

How  to populate the Route-Record is described twice:

Section 2.9:

   As noted in Section 6.1.9, a relay or proxy agent MUST append a
   Route-Record AVP to all requests forwarded.  The AVP contains the
   identity of the peer from which the request was received.

6.7.1.  Route-Record AVP

   The Route-Record AVP (AVP Code 282) is of type DiameterIdentity.  The
   identity added in this AVP MUST be the same as the one received in
   the Origin-Host of the Capabilities Exchange message.

Therefore the "rather clear" used by Jouni is almost an euphemism :)

I think that Luis was maybe misled by the following text:

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.

in which "find its own identity" might have been confusing out of context. But sections 2.9 and 6.7.1 should have clarified this misunderstanding. 

Whatever the reason for the proposed errata, it can be safely rejected.

Regards,

Lionel

> -----Message d'origine-----
> De : AAA-DOCTORS [mailto:[email-masked]] De la part de Jouni
> Envoyé : jeudi 9 février 2017 22:31
> À : Benoit Claise
> Cc : [email-masked]
> Objet : Re: [AAA-DOCTORS] [Technical Errata Reported] RFC6733 (4931)
> 
> RFC6733 Sections 2.9 and 6.1.9 are rather clear that a relay and a proxy MUST
> append a Route-Record to all requests forwarded with the identity of the peer
> from which the request was received. There is no text that a relay or a proxy
> should add its own identity. If the agent were to add its own identity it would
> result duplicate entries of Route-Records if there are more than one agent on
> the path. Additionally an agent adding its own identity to a Route-Record seems
> to go against a MUST Section 6.7.1.
> 
> > To:	[email-masked], [email-masked],
> [email-masked], [email-masked], [email-masked],
> [email-masked], [email-masked], [email-masked]
> > The following errata report has been submitted for RFC6733, "Diameter
> > Base Protocol".
> >
> > use "Reply All" to discuss whether it should be verified or rejected.
> > When a decision is reached, the verifying party can log in to change
> > the status and edit the report, if necessary.
> >

_________________________________________________________________________________________________________________________

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.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 10 Feb 2017 08:52:26 +0100

Thank you Lionel and Jouni.

Regards, B.