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

jouni korhonen <jouni.nospam@gmail.com> Tue, 18 September 2012 08:41 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 8FAAE21F877E for <dime@ietfa.amsl.com>; Tue, 18 Sep 2012 01:41:49 -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 KyIK1qA6CQ93 for <dime@ietfa.amsl.com>; Tue, 18 Sep 2012 01:41:48 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52D0621F8752 for <dime@ietf.org>; Tue, 18 Sep 2012 01:41:48 -0700 (PDT)
Received: by bkty12 with SMTP id y12so2833592bkt.31 for <dime@ietf.org>; Tue, 18 Sep 2012 01:41:47 -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=otw5S7T5gOVC2Ya/Kfb0WdWFXZZ1eLcQBMqylQCYGbg=; b=tJMEseV2MygFJ+Om1EWNn8NI3NE0smOW/57x4GvzwDT9bYRA/N420HhIITex1xW0cY XIkdPPJ8AMLWYldxoGORs0JWsne5BBpBvNfs7LWzd7aeUNGvrKdTGSLEpzi2rweQ54BS eWR1Sd/7OWcYlzTPIBYJ+iod0R4uwj86xFq+pXj1Nv3TPOD3QvnoMxW0o9JbwGnOLrVh 7aWZA+L+lfsgEQlT0mKotuncc3CfY+H6oBQP7zMoeeT9jG4sf3zpoFJi+mfkGb51s2IS K6g2qsfuzDp6CRt5Vu9viYU890sra/3wTrbcyKWX2M71lnhQRAS8euGi5FoVqp0YKhl/ Kd8Q==
Received: by 10.204.154.215 with SMTP id p23mr5330817bkw.53.1347957707312; Tue, 18 Sep 2012 01:41:47 -0700 (PDT)
Received: from ?IPv6:2001:6e8:2100:100:223:32ff:fec9:7938? ([2001:6e8:2100:100:223:32ff:fec9:7938]) by mx.google.com with ESMTPS id f7sm7036578bkv.1.2012.09.18.01.41.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 01:41:45 -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: <5F42DFF905CBA544A7BBB0909003E1A3148F14FCDB@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com>
Date: Tue, 18 Sep 2012 11:41:43 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5D0F77F-85F0-42C7-AD0B-B3F952928613@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> <5F42DFF905CBA544A7BBB0909003E1A3148F14FCDB@FRMRSSXCHMBSC1.dc-m.alcatel-lucent.com>
To: "VITON HORCAJO, Pedro (Pedro)" <pedro.viton@alcatel-lucent.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: Tue, 18 Sep 2012 08:41:49 -0000

Hi,

On Sep 18, 2012, at 9:43 AM, VITON HORCAJO, Pedro (Pedro) wrote:

> Thanks for your replies,
> 
> These questions came due to some interoperability small issue found with another vendor Diameter implementation.
> 
> I fully agree with your answers and interpretation, but sometimes in IOT's between different vendors, I think these little details are important.
> 
> Extra comments inline:
> 
> Thanks,
>  Pedro
> 
> 
>>> -----Original Message-----
>>> From: jouni korhonen [mailto:jouni.nospam@gmail.com] 
>>> Sent: Monday, September 17, 2012 10:07 PM
>>> To: VITON HORCAJO, Pedro (Pedro)
>>> Cc: Glen Zorn; dime@ietf.org
>>> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP
>>> 
>>> 
>>> Hi,
>>> 
>>> Few quick comments inline.
>>> 
>>> On Sep 17, 2012, at 3:09 PM, VITON HORCAJO, Pedro (Pedro) wrote:
>>> 
>>>> Glen,
>>>> 
>>>> Thanks for answering.
>>>> Maybe my original mail was too long, and I  might have not 
>>> have been clear enough.
>>>> 
>>>> Let me rephase my questions, in a shorter way:
>>>> 
>>>> 1.- The current text for Host-IP-Address AVP indicates the 
>>> value to send when transporting over SCTP.
>>>> But which value should be sent when transporting over TCP?
>>> 
>>> RFC3588bis 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. 
> 
>>> 
>>> This part is not SCTP specific. So at minimum you include 
>>> the address the
>>> very TCP connection comes from. Repetition but acceptable. 
>>> Also, Diameter
>>> host's DiameterIdentity may resolve to one or more IP 
>>> addresses but not
>>> necessarily to all of those. It is a DNS provisioning 
>>> matter. The Diameter
>>> node would know all its addresses it can use, so those 
>>> additional addresses
>>> would be included.
> 
> 
> I agree with this point, and all the possible addresses should also be sent with TCP, as well as with SCTP.
> But then, 
> what's the difference with respect to SCTP?
> Why does the RFC explicitely indicates SCTP for sending all possible IP addresses?

Because current TCP has no use of multiple addresses (except for failure
recovery.. maybe). On the other hand, SCTP is made for multi-addressing/homing.
And as I said, whether or not all IP addresses are provisioned e.g. into
DNS or statically is an operational issue. The less you provision the
easier. Let the underlying protocol take care of multiple addressing if
it is able to do that.

>>> 
>>>> 2.- What should a Diameter implementation do when 
>>> receiving the Host-IP-Address AVP?
>>> 
>>> In case of TCP.. that is more like FYI (unless someone plans 
>>> to hack MPTCP into
>>> Diameter some day). Or in case of transport failure, the 
>>> peer can select other
>>> IP for retrying the transport connection.
> 
> This retrying of the transport connection to the other advertised Host-IP-Address(es) sounds really interesting.
> But the current RFC text, doesn't even say that a peer MAY retry the transport connection to any of the other advertised Host-IP-Addresses.

The RFC says a DiameterIdentity may resolve to multiple IP
addresses of the peer. There is no restriction why a peer
would not try to connect to any of those.. just an implementation
detail allowed by the protocol.

If a peer is willing to reveal multiple IP addresses that it can
be reachable at, it must have a reason for it, specifically in a
case of TCP.

>>> 
>>> With SCTP, there is always RFC5061. Addresses can be added 
>>> to and deleted from
>>> an existing association. So for the responder it is good to 
>>> know that some IP 
>>> address maps to a DiameterIdentity of the initiator as those 
>>> might be added
>>> later on.
> 
> Sounds reasonable. 
> But as 3588bis doesn't say anything of doing any of this, an implementation doing nothing with the received Host-IP-Address values would be perfectly valid and compliant, I suppose.

Yes. Slightly dumb implementation but valid and compliant. There are a
lot of things that are unsaid regarding transport. For example, RFC3588(bis)
only refers to RFC793/5461 regarding the TCP protocol itself. However, for
a proper TCP implementation something +20 RFCs are needed (see RFC4614).

- Jouni


> 
> Thanks,
>  Pedro
> 
>>> 
>>> - JOuni
>>> 
>>> 
>>>> 
>>>> Best Regards,
>>>> Pedro
>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Glen Zorn [mailto:glenzorn@gmail.com] 
>>>>>> Sent: Monday, September 17, 2012 1:06 PM
>>>>>> To: VITON HORCAJO, Pedro (Pedro)
>>>>>> Cc: dime@ietf.org; glenzorn@gmail.com
>>>>>> Subject: Re: [Dime] [RFC3588bis-34] - Host-IP-Address AVP
>>>>>> 
>>>>>> 
>>>>>> On 09/17/2012 04:02 PM, VITON HORCAJO, Pedro (Pedro) wrote:
>>>>>>> Hi:
>>>>>>> After reviewing original RFC3588 and the lastest draft for 
>>>>>> 3588bis-34, 
>>>>>>> I have a couple of comments/questions related to the 
>>>>>> Host-IP-Address AVP
>>>>>>> 1.- I don't have clear the behavior of a diameter peer 
>>>>>> when SENDING 
>>>>>>> the Host-IP-Address AVP in the CER/CEA messages, if 
>>> using TCP to 
>>>>>>> transport Diameter.
>>>>>>> In sections 5.3.1 (CER), 5.3.2(CEA) and 5.3.5 
>>>>>> (Host-IP-Address AVP), 
>>>>>>> it indicates the behavior with respect to that AVP when 
>>>>>> using SCTP or 
>>>>>>> DTLS/SCTP as transport mechanism.
>>>>>>>   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.  
>>>>>> All source
>>>>>>>   addresses that a Diameter node expects to use with 
>>>>>> SCTP [RFC4960] or
>>>>>>>   DTLS/SCTP [RFC6083] MUST be advertised in the CER and 
>>>>>> CEA messages by
>>>>>>>   including a Host-IP-Address AVP for each address.
>>>>>>>   When Diameter is run over SCTP [RFC4960] or DTLS/SCTP 
>>>>>> [RFC6083],
>>>>>>>   which allow connections to span multiple interfaces, 
>>>>>> hence, multiple
>>>>>>>   IP addresses, the Capabilities-Exchange-Answer message 
>>>>>> MUST contain
>>>>>>>   one Host-IP-Address AVP for each potential IP address 
>>>>>> that MAY be
>>>>>>>   locally used when transmitting Diameter messages.
>>>>>>> That might lead to think that if using TCP, that AVP 
>>>>>> might/needs not 
>>>>>>> be sent.
>>>>>>> However, not sending it would be a contradiction with the 
>>>>>> CER/CEA ABNF 
>>>>>>> message format, that states that the Host-IP-Address AVP is a 
>>>>>>> mandatory AVP with at least 1 ocurrence :
>>>>>>> <CER> ::= < Diameter Header: 257, REQ >
>>>>>>>                  { Origin-Host }
>>>>>>>                  { Origin-Realm }
>>>>>>>               1* { Host-IP-Address } <------------
>>>>>>> ...
>>>>>>> I think it would be a good idea to clarify:
>>>>>>> A.- whether Host-IP-Address MUST/SHOULD/MAY included in CER/CEA 
>>>>>>> messages if using TCP
>>>>>> 
>>>>>> As you point out, the command definition for the CER 
>>>>>> requires at least 
>>>>>> on instance of the AVP.  What is unclear?
>>>>>> 
>>>>>> ...
>>>>>> 
>>>>>> 
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>