Re: [Dime] clearing of the Destination-Host AVP in the retransmitted request

Æstrid Smith <AE.Smith@f5.com> Wed, 03 April 2019 18:24 UTC

Return-Path: <prvs=989384043=AE.Smith@f5.com>
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 2102112010C for <dime@ietfa.amsl.com>; Wed, 3 Apr 2019 11:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=f5.com
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 TRhs2C0jEA1N for <dime@ietfa.amsl.com>; Wed, 3 Apr 2019 11:24:39 -0700 (PDT)
Received: from mail15.f5.com (mail15.f5.com [104.219.107.14]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B96012006B for <dime@ietf.org>; Wed, 3 Apr 2019 11:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=f5; t=1554315879; x=1585851879; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=7h60qAcCpbSqBgNMrMaPX+IxisLAKIDJXJcCawFMGak=; b=PV+F4qm0QjSHSG86nTqH5TGDmIgr3OrUnKNwa4VRwjLSKbaknq5mdna1 YL0FRbeHTQwsxARzIxojj/E30N+6YcBUGe96hVz8xAtpADENE2H4S18Zr DoLCZG85sRAXyhdRhjjKWqbUQxpptMzwSME9VjluA7o5oJiGNf0ewVaUD o+U7RbhLPqxnUo/2Z5elnYnpX4/L8/zodeA1BjGsqDq6ZA7sv2LmpRNFd qMN3luH5GClGVTYUX95nEpkumaCmFEoZyOA6eEqjFw8jyzetctaB6HFU3 /EKBJV4SlOzjakkgvj2xUTS1pAg/IbWtH7vQGMbgVH6EwfW3U+MHJwty1 A==;
X-IronPort-AV: E=McAfee;i="5900,7806,9216"; a="72819220"
X-IronPort-AV: E=Sophos;i="5.60,305,1549958400"; d="scan'208";a="72819220"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from seadev21.olympus.f5net.com ([192.168.180.71]) by mail.f5net.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Apr 2019 11:24:39 -0700
Received: from seadev21.olympus.f5net.com (localhost [127.0.0.1]) by seadev21.olympus.f5net.com (8.14.4/8.12.11) with ESMTP id x33IOcIT038868; Wed, 3 Apr 2019 11:24:38 -0700
Received: (from aesmith@localhost) by seadev21.olympus.f5net.com (8.14.4/8.14.4/Submit) id x33IOcsn038791; Wed, 3 Apr 2019 11:24:38 -0700
X-Authentication-Warning: seadev21.olympus.f5net.com: aesmith set sender to AE.Smith@f5.com using -f
Date: Wed, 3 Apr 2019 11:24:33 -0700
From: =?iso-8859-1?Q?=C6strid?= Smith <AE.Smith@f5.com>
To: "Poscic, Kristian (Nokia - US/Mountain View)" <kristian.poscic@nokia.com>
Cc: "dime@ietf.org" <dime@ietf.org>
Message-ID: <20190403182433.GY11770@seadev21.f5.com>
References: <AM0PR07MB5490C5A45B7C282661941E16ED5B0@AM0PR07MB5490.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AM0PR07MB5490C5A45B7C282661941E16ED5B0@AM0PR07MB5490.eurprd07.prod.outlook.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/wHBlITZJrbn17uyujccVvKUYtpU>
Subject: Re: [Dime] clearing of the Destination-Host AVP in the retransmitted request
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 03 Apr 2019 18:24:41 -0000

Hi Kris,

Your second scenario, an Unable_To_Deliver reply, can be generated on
predictive loop avoidance (6733 section 6.1.7) also.  Blacklisting the
peer for that destination-host is a good choice in that scenario.  But
I wouldn't think that clearing the destination-host is necessary,
because if the message could be retransmitted on a different path it
may eventually succeed.

If you're out of paths, though, as an ultimate fallback that seems
reasonable.

But then, I work almost exclusively with the base protocol in context
of a relay agent :) We don't touch the destination-host on any
message, unless configured otherwise.  From my reading of rfc6733
section 6.1, there isn't much latitude to include or omit a
destination-host on any particular message.
-- 
æstrid smith     -------------------
--<[ c y b e r  |  s o f t w a r e  |  e n g i n e e r ]>--
    ------------                     ------------------



On Sat, Mar 30, 2019 at 12:55:00PM +0000, Poscic, Kristian wrote:
> EXTERNAL MAIL: dime-bounces@ietf.org
> 
> Can someone clarify in which case should a Diameter client (DC)
> clear the Destination-Host AVP in the *retransmitted* request
> message:
> 
> 1. When the peer failover occurs - say the connection to node 1
>    fails and DC retransmit the request in the pending queue to node
>    2? Section 5.5.4 in RFC 6733 is not specific about this, and it
>    may even imply that the destination-host should not be
>    cleared. Even though the clearing it may be beneficial.
> 
> 1. When the client receives Diameter_Unable_to_Deliver (with E-bit
>    set) error message, which indicates that the node to which the
>    request is sent is unable to deliver the message to the
>    destination-host (or realm). In this case it would be beneficial
>    to blacklist this peer for this particular Diameter session. The
>    application (Gx/Gy/NASREQ) could then retransmit, but it clearly
>    does not make sense for Diam Base to send the message to the same
>    peer. Should the destination-host be cleared in this retransmit?
>    Some of this is mentioned in RFC 4006, sec 6.5, but again, it is
>    not clear.
> 
> I assume that when the original request message times out (due to no
> answer received) and it is retransmitted after Tx timer expires, the
> destination-host is not cleared in the retransmit.
> 
> Also, should the CC-Req-Num be the same on retransmit, or should the
> client use a new one?
> 
>                                             +---------+
>                                             |Diameter |
>                       +---------------------|         |
>          +---------+  |                     | Node 1  |
>          |Diameter |--+                     +---------+
>          |         |
>          | Client  |--+                     +---------+
>          +---------+  |                     |Diameter |
>                       +---------------------|         |
>                                             | Node 2  |
>                                             +---------+
> 
> Note: Diameter Node 1 and Node 2 could be relay agents OR the home
> servers (say redundant PCRFs, each with it's own unique peer name).
> I assume that DC should not make a decision on how to react based on
> the knowledge whether it has peering connection with the RA or the
> server.
> 
> This is in the context on plain Base, without any overload
> functionality (overload reports).
>
> Thanks,
> Kris

> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime