[Dime] FW: handling of unexpected direction of the messages
D'Alessandro Rosalia <rosalia.dalessandro@it.telecomitalia.it> Sat, 21 May 2016 13:29 UTC
Return-Path: <rosalia.dalessandro@it.telecomitalia.it>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B85A12D583 for <dime@ietfa.amsl.com>; Sat, 21 May 2016 06:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBDSSk3nohxx for <dime@ietfa.amsl.com>; Sat, 21 May 2016 06:29:11 -0700 (PDT)
Received: from TELEDG001RM001.telecomitalia.it (teledg001rm001.telecomitalia.it [217.169.121.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47E512D0AA for <dime@ietf.org>; Sat, 21 May 2016 06:29:10 -0700 (PDT)
Received: from TELMBXB04RM001.telecomitalia.local (10.14.252.31) by TELEDG001RM001.telecomitalia.it (10.19.3.111) with Microsoft SMTP Server (TLS) id 14.3.266.1; Sat, 21 May 2016 15:29:07 +0200
Received: from TELMBXA05RM001.telecomitalia.local (10.14.252.32) by TELMBXB04RM001.telecomitalia.local (10.14.252.31) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 21 May 2016 15:29:07 +0200
Received: from TELMBXA05RM001.telecomitalia.local ([fe80::cce8:4f15:2cf1:376]) by TELMBXA05RM001.telecomitalia.local ([fe80::cce8:4f15:2cf1:376%19]) with mapi id 15.00.1178.000; Sat, 21 May 2016 15:29:07 +0200
From: D'Alessandro Rosalia <rosalia.dalessandro@it.telecomitalia.it>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: handling of unexpected direction of the messages
Thread-Index: AdGycTKgUsA9NH7WQA+Ug64kPPGAgwA83xsy
Date: Sat, 21 May 2016 13:29:07 +0000
Message-ID: <e5c87276b27647379927fcd94ece52e0@TELMBXA05RM001.telecomitalia.local>
References: <7dbb33b925b34d25956c4a9d100c53b3@TELMBXA05RM001.telecomitalia.local>
In-Reply-To: <7dbb33b925b34d25956c4a9d100c53b3@TELMBXA05RM001.telecomitalia.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.14.252.240]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/kIo_9wETb6vA8P1SyhjX5KkHGrE>
Subject: [Dime] FW: handling of unexpected direction of the messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 May 2016 13:29:13 -0000
Dear All, TIM would like to submit a question on how to handle the conditions when a Diameter node receives an unexpected message from another Diameter peer entity. The specific scenario we are addressing is when a node named A gets a Diameter message which is correct from the protocol viewpoint but shall not be sent to this node A because this node A is not expected to receive the message but to send it from the application viewpoint. As an example this happens when the receiving node A is the legitimate sender of the message. Consequently this node A should expect an answer for this message and not a request. In our opinion, if an entity receives a request that it should not receive because, in the protocol, it should send the request and wait for the answer, this is clearly an error case. The request should not be processed and the result-code to use could be "DIAMETER_COMMAND_UNSUPPORTED" (command code not supported by the receiver) or alternatively, DIAMETER_UNABLE_TO_COMPLY. It seems that in the current version of the RFC 6733 this condition is not clearly addressed and we would like to include this case. What is your opinion? Looking forward to your reply, Rosalia d’Alessandro ------------------------------------------------------------------ Telecom Italia Information Technology Rosalia d’Alessandro Technical Security.SecurityLab G.Reiss Romoli, 274, 10148 Torino +39 011 228 8217 +39 3316001152
- [Dime] FW: handling of unexpected direction of th… D'Alessandro Rosalia