IETF68 DIME WG Open Issues for RFC3588bis Victor Fajardo (draft-ietf-dime-rfc3588bis-02.txt)

IETF68 DIME WG Overview Issue tracker in –Includes issues raised in two(2) diameter interop events –All issues from the 1 st interop have proposed solutions –Still have open issues from the 2 nd interop Current bis draft: rfc3588bis-02.txthttp:// rfc3588bis-02.txt –00 version does not include changes - only formatting updates –01 includes proposals for issues raised during the 1 st interop –02 includes proposals for issues raised during the 2 nd interop Relevant diffs – rfc3588.diff.htmlhttp:// rfc3588.diff.html – 1.diff.htmlhttp:// 1.diff.html

IETF68 DIME WG Issue Summary Bis open issues: 28, 33, 34, 35, 37, 38, 39, 50, 51, 52 Application related open issues: 42, 43 Remaining issues have proposed solutions –Issue 21: AAA/AAAS URI schemes has now been registered with IANA

IETF68 DIME WG Open Issues Issue 28: What is the error indication in case there are multiple Failed AVPs in a message Details: Is there a need to have more than one Failed AVP in a message ? If so, which Failed AVP does the Result-Code AVP refer to ? Status: No activity Issue 33: Why is there a need to Vendor-Specific- Application-Id AVP Details: If application id is flat and vendor app ids are in this same space, why is there a need to indicate the Vendor-Id ? The intent and usage of the AVP is never fully understood. Status: No activity

IETF68 DIME WG Issue 34: Precedence of routes discovered via redirect Indication Details: A question was raised on what would be the possible precedence order when messages matches cached routes generated from multiple redirect indications. The sample scenario is as follows: a. A message with realm='a.com' is redirected to host 'y' with redirect usage ALL_REALM b. A message with user='x' is redirected to host 'z' with redirect usage ALL_USER c. Both redirect routes (a) and (b) are cached then a message with realm='a.com' and user='x' arrvies. Which routing criteria should be used ? Status: No activity Notes: Strawman proposal in issue tracker. Also, not fully clarified if multiple cached redirect routes is allowed.

IETF68 DIME WG Issue 35: What is the expected representation and/or encoding of FQDN as used in Diameter identities Details: Does the FQDN have a syntatic meaning or semantic., i.e. Is it suppose to just look like an ASCII version of an FQDN or does it actually have to be DNS resolvable ? Status: No activity Notes: The encoding and semantic meaning has relevance in the following: Dynamic peer connection during redirect indication Host comparison as used in Election, Origin-Host verification etc.; Dependent on encoding (DNS encoding, Internationalization support etc). Current thinking seems to indicate that the we should revert to an ASCII form of representation as a default

IETF68 DIME WG Issue 37: Clarification on Election Details: Issue includes the following request clarification –Why the winner of the election would be the one to disconnect –Clarify the existing text on FQDN comparison, i.e.; something along the lines of If old-style FQDN ( [A-Za-z0-9-_]+ ) then a case insensitive comparison may be used. Otherwise, byte by byte. Solution: Some activity –02 version of the base protocol draft has the following changes for Sec 5.6.4: The election is performed on the responder. The responder compares the Origin-Host received in the CER with its own Origin-Host as two streams of octets. If the local Origin-Host lexicographically succeeds the received Origin-Host a Win-Election event is issued locally. To be consistent with DNS case insensitivity, octets that fall in the ASCII range 'a' through 'z' MUST compare equally to their upper-case counterparts between 'A' and 'Z', i.e. value 0x41 compares equal to 0x61, 0x42 to 0x62 and so forth up to and including 0x5a and 0x7a. Notes: This has co-relation with issue 35.

IETF68 DIME WG Issue 38: Need to state clearly what transport layer security version should be used Details: We need to clearly call out what kind of ClientHello envelope is to be used during initial TLS negotiation. Status: No activity Issue 39: Need for additional verification of received certificates when using TLS Details: A question was raised if there should be additional validation of received certificates, maybe against the Origin-Host. Status: No activity Notes: A strawman proposal is to use Subject Alternative Name (RFC3280) for certificate verification against Origin-Host

IETF68 DIME WG Application Specific Issues Issue 42: Which application id should be used in NASREQ accounting message ? Details: Should it carry the same app id as STR/STA, RAR/RAA and ASR/ASA ? Or does ACR/ACA carry base protocol accounting app id ? If so will "Acct-Application-Id = NASREQ" Status: No activity Issue 43: Interoperability Issues with DCC and Ro Details: DCC was routed using the normal application id and realm descriptor while Ro had embedded the application id into the Vendor- Specific-Application-Id. Status: No activity

IETF68 DIME WG Issue 50: Simplification of discovery process Details: Need to simplify the peer discovery mechanism (Sec 5.2 and related appendix): –Removal of some of the discovery schemes, i.e., SLPv2 and NAPTR –Discovery would be done via basic DNS queries, use of redirect agents and manual configuration Status: No activity Issue 51: Removal of End-to-End Security Framework Details: Removal of Sec 2.9 End-to-End security framework –Such security framework was never realized –Intra domain signaling (i.e. IMS) are assumed to be secure –Inter domain security is covered by TLS/IPsec. –Removal of p-flag in the AVP header Status: No activity

IETF68 DIME WG Issue 52: Removal of IPSec Details: Removal of IPSec references in the bis (Can be controversial) Reasons: –Typically, IPsec does not require interaction with applications unlike TLS –IPsec can be treated as a separate security measure that is transparent from a Diameter node Status: No activity