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

["VITON HORCAJO, Pedro (Pedro)" <[e-mail]>]

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:[e-mail]] 
>> Sent: Monday, September 17, 2012 10:07 PM
>> To: VITON HORCAJO, Pedro (Pedro)
>> Cc: Glen Zorn; [e-mail]
>> 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?





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



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

Thanks,
  Pedro

>> 
>> - JOuni
>> 
>> 
>> > 
>> > Best Regards,
>> >  Pedro
>> > 
>> >>> -----Original Message-----
>> >>> From: Glen Zorn [mailto:[e-mail]] 
>> >>> Sent: Monday, September 17, 2012 1:06 PM
>> >>> To: VITON HORCAJO, Pedro (Pedro)
>> >>> Cc: [e-mail]; [e-mail]
>> >>> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/dime
>> 
>>