Subject: [Dime] Issue Summary for rfc3588bis - based on the last interop event

From: Victor Fajardo <[email-masked]>
Date: Wed, 21 Feb 2007 12:22:11 -0500

Summary
-------
 
The following is a summary of issues raised during the last interop. 
Note that these issues are rolled into the interop report. Also, issues 
are mapped to tracking numbers in: 
http://www.tschofenig.priv.at:8080/diameter-interop/index
 
Issues List
-----------

#32 What is the set of application ids that should be returned in the CEA
 
   A question was raised on what is the set of application ids should  
   a diameter peer return in the CEA. Should it be:
 
   a. An intersection of its own set of app ids and its peer. OR
   b. All of its own supported app ids.
 
   Concerns          : Some edge devices may not be capable of storing  
                       all app ids of peers.
 
   Current consensus : It should return all of its own supported app ids.
                       The intersection can be computed locally by both
                       peers. It maybe an implementation decision but
                       edge devices concerned about storage need not keep
                       the ids. In general the received set of supported
                       apps would only be useful as a future hint about
                       the peers capabilities.

#33 Why is there a need for Vendor-Specific-Application-Id
 
   A question was raised on why do we need the vendor-specific-app-id
   if the app id space is flat and vendor app ids have an allocated  
   lot in this space.  
                        
   Current consensus  : The intent of this AVP was never fully understood
                        hence we just have to clarify what we currently
                        have and make sure we treat Vendor-Spec-App-Id
                        as an ordinary app id and ingore the vendor-id
                        associated with it.
                         
   Comments from Glenn McGregor: Does this play into the possible ability
                        to route DCC and Ro differently?

#34 Precedence of routes discovered via Redirect indications
 
   A question was raised on what would be the possible precedence order
   when messages matches routing criterias in multiple cached redirect
   routes. The sample scenario is as follows:
 
     a. message with realm='a.com' is redirected to host 'y' with usage 
ALL_REALM
     b. message with user='x' is redirected to host 'z' with usage ALL_USER
     c. both redirect routes (a) and (b) are cached
     d. message with realm='a.com' and user='x' arrvies.
 
   Strawman proposal: The order would be
                         DONT_CACHE
                         ALL_SESSION
                         ALL_USER
                         REALM_AND_APPLICATION
                         ALL_REALM
                         ALL_APPLICATION
                         ALL_HOST
 
   Comments from 3588 Authors (Glenn Zorn):  
 
      This should not happen because the intent is to have only on cached
      redirect route at any given time. If a new redirect route was 
injected,
      it would replace any existing cached route.

   Comments from Glenn McGregor:
   
      Another possible point of interpretation is what is the scope of
      the redirect info? Should it apply to requests before a peer is
      chosen, or does it only active when picking a peer that sent the
      redir info.
 
   Consensus: Discussion continues

#35 What is the expected representation and/or encoding of FQDN as used 
in diameter identities
 
   The question raised comes in two parts:
 
   1. Does the FQDN have a syntatic meaning or semantic., i.e. Is it 
suppose
      to a) just look like an ascii version of an FQDN or b) does it 
actually have
      to be DNS resolvable ?
 
   2. If the answer to (1) is (b) then how do we deal with the different 
DNS FQDN
      transliteration/encoding ? Specifically how do we do comparisons ?

   Comments from 3588 Authors (Jari Arko): For the most part it is
            interesting to diameter from the point of view of comparing
            identities in usage such as lookups. My quick guess is that
            there is no need to do a DNS lookup. I could be wrong. 
Resolution
            maybe only be needed when you a redirect for a particular 
server.
 
   Comments from 3588 Authors (Glen Zorn): With regards to FQDN, you still  
            have a problem since the diameter identifier was expressed 
in FQDN
            and I remember that the internationalization stuff was 
ongoing at  
            the time the diameter spec was being defined. So you did not 
want  
            to guess what they are going to do and what FQDN would have 
become  
            would be fine.
 
            You have to make a new rule. You can have a bunch of different
            names in DNS and one of them has to match what you claim is 
your
            diameter name. You might have to say what transliteration 
method
            is used. It gets real complicated. We need to talk to some 
expert
            in this field to get clarification.
 
   Consensus: Need to talk to experts to do futher clarification.
 
   Notes: See interop minutes for full details of the discussion

#36 Relevance of vendor-id when computing common applications in CER/CEA 
exchange.
 
   A suggestion was made to add text stating that vendor-id will not be 
used
   as a descriminator when computing common applications between peers 
during
   capabilities exchange.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.
 
   Notes: 01 version of bis document mentions that vendor-id is not used in
          discriminating routes.
          
   Comments from Glenn McGregor: Should AUTH vs ACCT be used to 
determine intersection?

#37 Several clarification on election
 
   1. A question was raised on why the winner of the election would be 
the one
      to disconnect.
   
      Answer from 3588 Author (Jari Arko): It was thought that the 
winner of
      the election should do less work to managed the connection as 
oppose to
      the looser.
 
   2. A suggestion was raised on changing the text regarding the 
lexographic
      comparison (alpabetical) in Sec 5.6.4. The text should simply say 
that
      a lexographical comparison of the identities is done, however that 
identity
      (FQDN) maybe encoded (ascii, unicode, internatinalization etc) and
      however such comparison is performed in that encoding.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.
              
   Comments from Glenn McGregor: Not clear to me which has more or less 
work.
              Once you have a socket handle, it doesn't really matter which
              end initiated the connection. (At least in the languages/OSs
              I've worked in).
              
   Proposal from Glenn McGregor: If old-style FQDN ([A-Za-z0-9-_]+) then a
             case insensitive comparison may be used. Otherwise, byte by 
byte.

#38 Need to state clearly what transport layer security version should 
be used
 
   A suggestion was raised in which 3588 should clearly state which 
transport  
   layer security version should be used. There where issues when one 
implementation
   uses SSLv2 as opposed to TLSv1. See minutes for details.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.
              
   Comments from Glenn McGregor: Actually, we need to clearly call out what
              kind of ClientHello envelope is to be used. Everyone so 
far has
              initially attempted to negotiate TLS inside a SSLv2 client 
hello
              message.

#39 Need for additional verification of received certificates when using 
TLS
 
   A question was raised if there should be additional validation of 
received
   certificates, maybe against the origin-host.
 
      Strawman from Glenn McGregor: Match the CN of the certificate with 
the
                                    origin-host of the peer
 
      Comments from 3588 Author (Jari Arko): How would you go about this ?
            Would you add something in the certificate
            that says you can use this to authenticate for example
            domain foo.com and anything beyond that is not valid. There
            are definitely questions in this area. Worth investigating.
 
      Consensus: Discussion continues
 
      Notes: See interop minutes for full details of the discussion
      
      Comments from Glenn McGregor: One of the guys here recommended we look
             at RFC 3280 - Subject Alternate name.

#40 Clarify the minimum amount of information a relay has to inspect for 
a message
 
   A question was raised on how much processing a relay agent must 
perform for
   every message that it forwards.
 
   Consensus:  You cannot avoid some validation of the message since a 
relay needs
               to inspect not only the message header but relevant 
routing avps
               as well. At the minimum, full validation will be done by 
a relay
               on the header and relevant routing avps and some sanity 
check will
               be peformed for the remaining avps since parsing the 
message requires  
               walking through most/all of the avps headers.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.

#41 Description Clarification and Terminology changes
 
   1. A suggestion was made that since routing information is not 
restricted to
      realms and app ids espcially with regards to redirect routes, the 
"Realm
      Routing Table" should be changed to "Routing Table"
 
   2. A suggestion was made that we calrify the description of 
NO_COMMON_APPLICATION.
      It should read as "A node that is not acting as a relay and 
supporting  
      a specific set of application that has a empthy intersection with 
the set
      of application advertised by its peer MUST return 
NO_COMMON_APPLICATION
      in the CEA".
 
   3. A suggestion was made that additional text stating "Vendor-Id or 
Supported-Vendor-Id
      SHOULD NOT be zero" needs to be made.
 
   4. A suggestion was made to clarify description of the routing table to
      account for addition of redirect routes. The suggested text is:
      "Realm and application ids are the minimum supported routing 
criteria,
       additional routing information maybe needed to support redirect 
semantics"
       
   5. Don't send 'supported-vendor-id = 0' CER/CEA. Don't the send the 
same ID
      multiple times.
 
   Consensus: Textual changes to clarify the current process is needed. No
              protocol or specification changes required.

#42 Interoperability of DCC and Ro

    During the last interoperability event. There was an issue with 
regards to
    interoperability of DCC and Ro. DCC was routed using the normal app 
id and realm
    descriptor while Ro had embedded the application id (???) into a VSAI.
    
    A question was raised on whether DCC and Ro should be routed/treated as
    different applications.
    
    Comments from Tolga Asveren:
    
    IMHO they should be, but it is hard for us to do anything about it.
    The problem is that 3GPP did not use a new Application-Id. They 
needed to
    use a new one because they defined lots of new AVPs with M-bit set. 
Ro and
    DCCA are used for the same purpose but the semantics are different 
due to
    the new AVPs defined by Ro. IMHO, in such situations people 
shouldn't try to
    use "initiative", they just need to follow the rule which dictates 
that a
    new application has to be defined. We can document that there is a 
problem
    and hint that presence of Ro defined AVPs could be used for routing
    purposes.
    
    Regarding the confusion of the contents of DCCA messages, I guess 
the main
    problem is that command ABNFs are defined genericly, e.g. there is no
    separate ABNF for CCR for session and different event based 
scenarios. So,
    only AVPs, which are mandatory for all scenarios are marked in the 
ABNF as
    mandatory, e.g. User-Name in CCR is mandatory for session based 
messages and
    for event based messages except Service Price Enquiry, hence it is not
    marked as a mandatory AVP. There seem to be two options: Defining 
command
    ABNFs per scenario or relying on textual description (this is pretty 
much
    what is done now).

#43 Which application id should be used in NASREQ accounting

    A question was raised on which application id should be used in NASREQ
    accounting message. A further consequence of this are:

    Comments from Glenn McGregor:
        
    Does "Acct-Application-Id = NASREQ" need to be separately announced 
in CER/CEA
    exchange? Do we want to call out separate routing for AUTH vs ACCT 
NASREQ?
    Or is it like STR, RAR,  ASR commands that come for free?

#44 Diameter Extensibility Clarification

    While writing the diameter extensibility guidelines, a question was 
raised
    on the following text. The suggestion stated below requires some 
relaxation
    of the diameter application id allocation rules.
    
    "In order to justify allocation of a new application identifier,
     Diameter applications MUST define one Command Code, or add new
     mandatory AVPs to the ABNF."
    
    Comments from Tolga Asveren:
    
    IMHO, the second part of this sentence causes much confusion. Adding 
an AVP with
    M-bit set but optional in command ABNF MUST cause a new 
application-Id to be
    used, which according to that sentence doesn't. I would prefer the 
following:

    (The following is a change to RFC3588. IMHO, it is a necessary 
change, but I do
    not know whether this document is the right place to do so. Is this 
again bis
    material? If so and if we want to stick to what is said in the 
RFC3588, would it
    be really useful to clarify something we want to change (of course 
only if you
    guys agree with my understanding :-) )

    Proposed text:
    
    In order to justify allocation of a new application identifier, Diameter
    applications MUST define one Command Code, add a new AVP with M-bit 
set to
    one of the existing commands or change the state machine/processing 
rules for
    an existing application.

#45 Clarify the possible accounting models

    While editing the application design guidelines doc, it was realized 
that
    the possible accounting usages and models was not clearly described in
    RFC3588. The text below is a proposal to add a new section describing
    these models.
    
    Comments from Tolga for text describing accounting models in the bis:

    Application Accounting Models
   
    Applications MAY use one of the following accounting models:

     o Coupled Accounting

       In this model, the same entity provides both application processing
       logic and accounting functionality. Accounting messages are sent by
       populating the Application-Id field in the message header with the
       application identifier of the corresponding application. No special
       behavior is exptectd during capability exchange procedure or during
       message routing.

     o Split Accounting

       This model assumes presence of a standalone accounting server, which
       MAY possibly be handling accounting for multiple applications. 
Accounting
       messages are sent by using the base accounting application 
identifier 3
       in the Application-Id field in the message header. Accounting servers
       operating in this mode MUST advertise the identifiers for the
       applications for which they can provide accounting service in the
       Acct-Application-Id AVP during capability exchange procedure. For 
split
       accounting scenario, accounting messages MUST include the 
identifier of
       the corresponding  application in the Acct-Application-Id AVP. 
During
       routing of accounting messages Acct-Application-Id AVP value MUST 
be used
       as well in addition to Application-Id to select an appropriate 
accounting
       server. It should be noted that all intermediary nodes, e.g. relay
       agents, MUST be able to route accounting messages by considering 
both the
       Application-Id in the message header and Acct-Application-Id AVP 
in order
       to utilize split accounting.

regards,
victor

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime