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

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

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
B.- if it is not needed, indicate that AVP as opcional 1*[Host-IP-Address] in the CER/CEA ABNF. However, leaving it as optional, might lead to interoperability issues between an implementation not sending it, and another implementation expecting it as mandatory (as per current RFC 3588)

--------------------
2.- On the other side, I haven't been able to find anywhere the behavior a Diameter implementation should have when RECEIVING that AVP, both with TCP and SCTP as transport methods.

A.- Should it check the source IP address of the received CER/CEA message belongs to the values of the Host-IP-Address AVP?
But what would be the purpose of that? Prevent NAT traversal?

And what to do then if the Source IP Address doesn't match?



B.- With SCTP, I thought initially the Diameter implementation could interface with a SCTP layer primitive to add the rest of the advertised IP addresses in Host-IP-Address, as possible addresses for this endpoint in the already established SCTP association.

However, after glancing over SCTP RFC 4960 (sections 3.3.2.1 & 5.1.2), it seems that the remote IP addresses of an association may be exchanged/learnt only during the association establishment by using the Options in the INIT chunk.

Therefore, if my assumption is right that it is not possible to add/remove a remote endpoint  IP address to an already established association,
what's the point in having a Host-IP-Address AVP in the CER/CEA message?

Just for historical reasons?


In any case, I think it would be nice to clarify the utility of Host-IP-Address AVP, as well as a diameter implementation expected behavior, both when sending it and receiving it, when using TCP and SCTP.



Thanks,
  Pedro


      \\\|///
     \\ ~ ~ //
     (/ @ @ /)
___oOOo-(_)-OOo_________________________
Pedro Viton         Tlf:+(34) 690 96 4740

[e-mail]<mailto:[e-mail]>

C/ Maria Tubau 9 (28050) Madrid SPAIN
___________Oooo.____________________________
    .oooO  (   )
    (   )   ) /
     \ (   (_/
      \_)