Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP

jouni korhonen <jouni.nospam@gmail.com> Fri, 21 September 2012 07:24 UTC

Return-Path: <jouni.nospam@gmail.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 2807821E8083 for <dime@ietfa.amsl.com>; Fri, 21 Sep 2012 00:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5avgfKMUwD3q for <dime@ietfa.amsl.com>; Fri, 21 Sep 2012 00:24:46 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A29021E8051 for <dime@ietf.org>; Fri, 21 Sep 2012 00:24:45 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so752440wgb.13 for <dime@ietf.org>; Fri, 21 Sep 2012 00:24:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XxlRYBeZcPIN1RhHwb2hdMMwWVXLSt9jpE9UCmhVYRE=; b=UC9eLFV/la2azpja03PmaQNn09O6ek8Maq/oxe3HvyzIQU9ByllFAVP6IJ2zvodyGM cocBIPUesjdR21ROOtK2hubAi2uoT0+bcebnMc3uzxm6NTp3SVC2ydx7IBenesP6Wg+v punUu2FFFAxYJf91dbmKFel8B+ZQCDAE5S8KDRWZwALRuLUhw90gB2pI4AXlLc9JCM8Q 0hjoyW2lPE3I5VjOKXUm7mX+aSVaZuOVMeil6N25lk62JyXf3BVSTiZDK8lRmCta07VM Y9bzsFv+ZpJ1zzdTxDQk7rkEChfOwgHXyIcTme+YwwZ89QhhM8HOYCtnGSOH7kogAQC0 BFag==
Received: by 10.180.91.169 with SMTP id cf9mr1983660wib.1.1348212285094; Fri, 21 Sep 2012 00:24:45 -0700 (PDT)
Received: from [10.255.134.5] ([194.251.119.201]) by mx.google.com with ESMTPS id hv8sm2932091wib.0.2012.09.21.00.24.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 00:24:44 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <505C0F10.3020106@gmail.com>
Date: Fri, 21 Sep 2012 10:24:40 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <8314502B-CD54-460C-B3E0-A3401E3F6BC5@gmail.com>
References: <5F42DFF905CBA544A7BBB0909003E1A3148F14F7C6@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <50570410.9000708@gmail.com> <5F42DFF905CBA544A7BBB0909003E1A3148F14F987@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com> <E4A11012-4F89-455F-AC98-57F188456D91@gmail.com> <50585DBF.20502@gmail.com> <593C8CD1-DAAC-4E39-BE6F-0FA754C706B1@gmail.com> <8BAB668F-5B65-4FBE-B49B-833EAFE47D49@nostrum.com> <99463A4A-9840-43B2-B29F-D942FD7AB757@gmail.com> <B5943A55-6A2A-4977-A06C-B9DA9FDABF1E@nostrum.com> <505C0F10.3020106@gmail.com>
To: Glen Zorn <glenzorn@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 21 Sep 2012 07:24:47 -0000

Glen,

On Sep 21, 2012, at 9:54 AM, Glen Zorn wrote:

> On 09/21/2012 01:24 AM, Ben Campbell wrote:
> 
>> This doesn't really make sense  to me: I was under the impression that
> > a TCP connection was between two unique addresses. Yes, a box might
> > ___have_ a whole bunch of addresses it _could_ use, but that seems
> > irrelevant in the case of TCP (but not SCTP).
> >>>>
> >>>> Sure TCP is between just two IPs. I never claimed otherwise.
> >>>> What I mean that say a Diameter node has IP1 to IP5. Only IP1
> >>>> has a A/AAAA record or given out to other parties for static
> >>>> configuration. During the CER/CEA (and the TCP connection
> >>>> established to IP1) it tell in CEA that "I btw also have IP2 to
> >>>> IP5". A clever implementation can make use of this e.g. for the
> >>>> transport failure case I described.
> >>>>
> >>>
> >>> This actually leads me to agree with the original poster that the
> >>> behavior surrounding Host-IP-Address is underspecified. The
> >>> problem is, "clever implementations" are bad for
> >>> interoperability. If that (or other) behavior is desired, it
> >>> should be documented. Otherwise any behavior beyond "use it for
> >>> informational purposes only" is not likely to work across
> >>> implementations.
> >>
> >> First, we all agree that having more than one Host-IP-Address in
> >> case of TCP is unnecessary. However, I am interested what possible
> >> (error) case you have in mind that could cause interoperability
> >> issue?
> 
> The draft says:
> 
>   The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
>   to inform a Diameter peer of the sender's IP address.
> 
> Suppose that I send, instead of one address, three (assuming the use of TCP).  Which one do you use?  What if the list doesn't contain the address from which the CEr/CEA command was sent?  If my solution to transport failure is to send you three addresses 

Obviously you use the address you received CER/CEA from.. and if that address is not included in the
list of Host-IP-Addresses then the other end is on weeds.

> assuming that you'll try them sequentially and you don't understand that, my scheme fails and since you only have one registered address for me, this could cause a much longer outage than if my network admins just did their job and registered all the available addresses in the DNS.
> 
>>> 
> >
> > I don't have a specific error in mind. My intent was to point out
> > that while there may be interesting things you can do with
> > Host-IP-Address (like the example you gave), anything that requires a
> > mutual understanding between the client and server aren't going to
> > work unless the understanding exists. In you example, using
> > Host-IP-Address to tell the peer about other available addresses to
> > be used for load balancing and/or failover won't work across
> > implementations unless it's documented somewhere.
> >
> > The original poster pointed out that they were seeing real IOT issues
> > because different implementors interpreted the spec differently in
> > regards to Host-IP-Address. Assuming that these differences were due
> > to reasonable interpretations of the spec, rather than simple
> > misunderstandings, that's a pretty big indicator that there's a
> > problem.
> 
> I would be inclined to write a short draft clarifying that, in the case of TCP, exactly one instance of the Host-IP-Address MUST be included in the CER/CEA messages.

Might be a good thing.

- Jouni

> 
> ...
>