Subject: [Dime] Request routing considerations in 3588bis. was: RE: 3588bis review

From: <[email-masked]>
Date: Wed, 13 Feb 2008 13:04:51 +0100

Victor,

After reading (again) the request routing part of the 4588bis,
I think the I-D should say more about the realm-based routing.
For example, RFC4282 that this I-D also references to, allows
"source routing" using decorated NAIs. There are already specs
out there that assume Diameter realm routing supports this
feature. To my understanding at least 3GPP and WiMAX use this
feature to implement various roaming scenarios. However, I
cannot find any indication of such in 3588bis. Basically, I
would propose adding some text to sections 6.1. and 6.1.9.
in order to cover decorated NAIs.

Below is a draft proposal for a new text:

6.1. Diameter Request Routing Overview

   ... its ABNF.  For Diameter clients, the value of the Destination-
   Realm AVP MAY be extracted from the User-Name AVP, or other
   application-specific methods. For Diameter relays and proxies, the
   values of the User-Name AVP and the Destination-Realm AVP MAY be
   modified if the User-Name AVP contains a NAI with multiple realms
   (see RFC 4282 [RFC4282] Section 2.7 Realm Construction).

   ...

6.1.9. Relaying and Proxying Requests

   ...

   Relay agents do not require full validation of incoming messages.  At
   a minimum, validation of the message header and relevant routing AVPs
   has to be done when relaying messages.

   If both User-Name and Destination-Realm AVPs are present, then a
relay
   or proxy SHOULD check whether the the User-Name AVP contains a NAI
   with multiple realms (as described in RFC 4282 [RFC4282] Section
2.7).
   If multiple realms are found in the NAI then the following steps are
   done:

   o The NAI in the User-Name AVP is processed and modified according to
     the NAI conversion rules defined in RFC 4282 [RFC4282] Section 2.7.

   o The Destination-Realm AVP is modified with the updated realm
     information extracted from the User-Name AVP.

   o The request is routed normally as described in Section 6.1.6.

Any comments etc ?

Cheers,
	Jouni

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]] 
> Sent: 23. tammikuuta 2008 1:31
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]
> Subject: Re: 3588bis review was: Re: [Dime] (no subject)
> 
> 
> Hi Jouni,
> 
> Thanks :) We'll fix the nits.
> 
> -- victor
> 
> > Hi Victor,
> >
> > I have two more nits ;)
> >
> >  o Section 4.1 AVP format acsii figure. It seems you
> >    forgot to put the deprecated 'P' bit back even if
> >    the text mentions it again.
> >
> >  o Appendix B and DNS RR examples are still formatted
> >    wrong imho. They should be:
> >
> >     ;;          order  pref  flags   service      regexp  
> replacement
> >     IN NAPTR    50     50    "s"     "AAA+D2S"    ""      
> >       _diameter._sctp.example.com
> >     IN NAPTR    100    50    "s"     "AAA+D2T"    ""
> >       _aaa._tcp.example.com
> >
> >   and:
> >
> >     ;;       Priority  Weight  Port    Target
> >     IN SRV   0         1       5060    server1.example.com
> >     IN SRV   0         2       5060    server2.example.com
> >
> >
> > Cheers,
> > 	Jouni
> >
> >
> >   
> >> -----Original Message-----
> >> From: Victor Fajardo [mailto:[email-masked]]  
> >> Sent: 22. tammikuuta 2008 18:26
> >> To: Jouni Korhonen
> >> Cc: [email-masked]
> >> Subject: Re: 3588bis review was: Re: [Dime] (no subject)
> >>
> >>
> >> Hi Jouni,
> >>
> >> Thanks for the review and sorry for the very late reply. I'm 
> >> currently updating 3588bis based on comments from reviewers. 
> >> I've integrated most of your comments below. Some answers to 
> >> your post are inlined:
> >>
> >>
> >>     
> >>>> ------------------
> >>>>
> >>>> o This bis version e.g. deprecates a few things from the 
> >>>>         
> >> RFC3588 like
> >>     
> >>>>   E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are 
> >>>>         
> >> considerable
> >>     
> >>>>   changes in the security department.  I would like to 
> see a small
> >>>>   section actually describing the major changes. For a new 
> >>>>         
> >> reader that
> >>     
> >>>>   would be a nice quick-start.
> >>>>         
> >> Good idea.
> >>
> >>     
> >>>> o Application Id has been written using 3-4 different conventions
> >>>>   in the text. Pick one and stay with it ;)
> >>>>         
> >> Ok.
> >>
> >>     
> >>>> Section 4.1. AVP Header
> >>>>
> >>>>   I would actually leave the P-flag in place but have a 
> description
> >>>>   in flags related text stating something like "The 'P' 
> >>>>         
> >> bit has been
> >>     
> >>>>   deprecated and MUST be set to zero when sending and ignored on
> >>>>   receiving". IMHO this is more cleaner way than 
> changing it to 'r'
> >>>>   bit.
> >>>>         
> >> Good point.
> >>
> >>
> >>     
> >>>> 6.11. Vendor-Specific-Application-Id AVP
> >>>>                
> >>>>      "..           
> >>>>     The Vendor-Id AVP is an informational AVP pertaining 
> >>>>         
> >> to the vendor
> >>     
> >>>>     who may have authorship of the vendor-specific 
> >>>>         
> >> Diameter application.
> >>     
> >>>>     It MUST NOT be used as a means of defining a completely 
> >>>> separate           
> >>>>     vendor-specific application identifier space.           
> >>>>                
> >>>>   o A question.. now that section 11.3. under IANA 
> >>>>         
> >> considerations say:
> >>     
> >>>>   "Vendor-Specific Application Identifiers, are for 
> >>>>         
> >> Private Use. Vendor-
> >>     
> >>>>    Specific Application Identifiers are assigned on a 
> >>>>         
> >> First Come, First
> >>     
> >>>>    Served basis by IANA."
> >>>>
> >>>>   o what is the actual value of having Vendor-Id AVP in 
> >>>>         
> >> the group if
> >>     
> >>>>     the vendor specific application Ids need to be 
> >>>>         
> >> reserved from AINA
> >>     
> >>>>     anyway? If it is just FYI, couldn't that be removed..? 
> >>>>         
> >> though that
> >>     
> >>>>     might hurt backwards compatibility, slightly ;)
> >>>>         
> >> As you mentioned, backward compatibility is the reason why we 
> >> had to keep vendor-id avp despite it being redundant from the 
> >> base protocol perspective. If I'm not mistaken, its actually 
> >> being used by other SDO's.
> >>
> >>     
> >>>> 6.11. Vendor-Specific-Application-Id AVP   
> >>>>                 
> >>>>     <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >   
> >>>>     { Vendor-Id }   
> >>>>     ({ Auth-Application-Id } /   
> >>>>     { Acct-Application-Id })
> >>>>
> >>>>   o I think the above does not comply with the ABNF described in
> >>>>     section 3.2.
> >>>>         
> >> We've fixed this by integrating reviews from Ralph.
> >>
> >>
> >> regards,
> >> victor
> >>
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/dime
> >>
> >>     
> >
> >
> >
> >   
> 
> 
_______________________________________________
DiME mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Wed, 13 Feb 2008 18:45:38 +0100

Hi Victor,

> Hi Jouni,

[snip]

> > Any comments etc ?
> >   
> 
> Mmmm .... for me, putting decorated NAI dependencies in the base is 
> probably going to confuse folks. To me decorated NAI is a 
> solution to a 
> very specific problem that should not be generalized in the 

It is a specific solution to enforce certain business models.

> base. There 
> are other competing solutions to the "source routing" issue that does 
> not require changes to basic routing. So I think it is better if that 
> happens outside existing routing procedures.

I understand your concern regarding the base protocol specification.
However, I really would like to know how to deal with decorated NAIs
and Diameter routing in general. IMHO we need it documented somewhere
in IETF space. Can I assume e.g. NASREQ & EAP handle it, if those boxes
implement 3588bis? Or do I always need a new application that is
equivalent to e.g. EAP apart from modified routing?

Cheers,
	Jouni

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 13 Feb 2008 14:40:56 -0500

Hi Jouni,

> equivalent to e.g. EAP apart from modified routing?

I understand. Though it maybe more appropriate to document these issues 
in related extension draft (like Tina's draft).

regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 13 Feb 2008 09:42:22 -0500

Hi Jouni,

Mmmm .... for me, putting decorated NAI dependencies in the base is 
probably going to confuse folks. To me decorated NAI is a solution to a 
very specific problem that should not be generalized in the base. There 
are other competing solutions to the "source routing" issue that does 
not require changes to basic routing. So I think it is better if that 
happens outside existing routing procedures.

regards,
victor