Re: [Dime] Dime NAI Routing

[jouni korhonen <jouni.nospam at gmail.com>]

I had some more thoughts around Avi's proposal and made a small  
summary and comparison of pros & cons. NAIdime means the solution  
proposed in the Dime draft. NAIavi is Avi's proposal.

1) All intermediates and peers support their own proposed solutions and
   no new application
   - Both NAIdime & NAIavi work fine

2) Some intermediates do not support NAI decoration, the destination  
Diameter server
   supports NAI decoration and no new application
   - NAIdime causes an "early" consumption of the request, which would
     cause the auth/authz fail in all realistic situations
   - NAIavi would cause a routing loop and auth/authz to fail in all  
realistic
     situations. However, this applies only if there are more than  
one intermediate
     realms and the non-supporting realm is not next to the final  
destination.

3) Some intermediates do not support NAI decoration, the destination  
Diameter server
   does not support NAI decoration and no new application
   - NAIdime has the same issue as in 2)
   - NAIavi auth/authz probably fails as the User-Name does not  
correspond to the
     user identity (it is still decorated). This depends on the used  
auth/authz
     method though.

4) Some intermediates do not support NAI decoration, the destination  
Diameter server
   supports NAI decoration, new application
   - Both NAIdime & NAIavi work ok (non-supporting agents get bypassed)

5) Some intermediates do not support NAI decoration, the destination  
Diameter server
   does not supports NAI decoration, new application
   - not applicable

6) Routing "processing" in an agent that supports NAI routing
   - NAIdime modifies both User-Name and Destination-realm. Final
     routing decision still based on Destination-Realm+Application-id  
as
     defined in unmodified rfc3588.
   - NAIavi modifies only the User-Name. Final routing decision needs
     modifications to rfc3588 request routing as sometimes the routing
     is done based on the User-Name+Application-id and sometimes based
     on the Destination-Realm+Application-id.


DId I miss some scenario? Or did I get some scenario wrong?

Summarizing the above:

1) is trivial and probably the desired deployment scenario.
4) NAI routing coupled with a new application is the safe choice. Both
   NAIdime & NAIavi always work OK.
3) is a valid scenario where both NAIdime & NAIavi have issues. NAIavi
   has probably less issues depending on the used auth/authz method.
2) here NAIavi has an advantage. From a protocol point of view it is  
not ok to
   define a solution that is known to break in other than a naive  
deployment
   scenario. From a practical point of view, I think the naive  
deployment
   scenario is probably what gets deployed in real life. However, one
   could never be sure.
6) NAIavi probably requires more code changes in the existing rfc3588  
code base.
   This could be a theoretical disadvantage though. I cannot really  
judge
   the amount of work required in other's products.

So.. comments? Honestly, I tried to be objective ;)

Cheers,
	Jouni



On Mar 11, 2009, at 12:38 AM, jouni wrote:

> Hi Avi,
>
> Thanks for the valuable input. See some comments inline.
>
> On Mar 10, 2009, at 3:56 PM, Avi Lior wrote:
>
> > I have inline comments as well as new comment:
> >
> > The over arching problem as I see it is that when you read the  
> > document, at least the introduction and abstract you get the sense  
> > that the draft is intending to fix base diameter behavior.
>
> That is the intent.
>
> > But in responses I get, I get the feeling that the intent is really  
> > to have an Application based routing scheme using NAI.
>
> Applications are recommended for cases where the requests pass  
> through realms/networks where one cannot always claim that "all my  
> agents implement RFC3588 + RFC-NAI-Routing". If you know that your  
> networks support RFC3588 + RFC-NAI-Routing, there is no need to go  
> for a new application. Section 4.3 is a recommendation for backwards  
> compatibility.
>
>
> > If you are trying to fix base then we need a robust backwards  
> > compatible way of doing things.  As well, we can argue whether or  
> > not it should be placed in DIME.  There is more work to do.
>
> We at least seem to agree that something needs to be done ;)
>
> > If you are trying to write a document that describes how one would  
> > do Application routing using NAI. Then that does not belong in base  
> > so we should stop debating that.  And actually in this case what  
> > you are doing is fine and you are probably there.
> >
> > So which is it?  And once we pick we should be clear in the text.
>
> Definitely this is not about doing only application routing using  
> NAI. One of the goals is to be able to request a vendor e.g. "give  
> me an agent that implements RFC3588/RFC-NAI-Routing", without being  
> more specific on applications.
>
> I reread Sections 4.1-4.2. Which parts are unclear? I am happy to  
> reword.
>
> > We could come up with a hybrid solution by the way.
> >
> > If the priority is to make sure that the packet gets to the  
> > destination, then:
> > You set the destination-realm to the final destination and  
> > intermediaries that support decorated NAI use the decorated NAI  
> > without modification to the destination-realm.  Intermediaries that  
> > don't know about decorated NAI will just perform the destination- 
> > realm routing.  As you point out you get looping but its not  
> > infinite looping.  At least the message would get to the final  
> > destination.
>
> The agent would send an error indicating a routing loop and then the  
> agent MAY try an alternate route.. which would result another  
> routing loop. I see no way out of this.
>
> > If NAI routing is the most important thing then you set the  
> > destination-realm to the next hop of the Decorated NAI.  Each hop  
> > that supports this scheme will use the decorated-nai and will  
> > update the realm.  If a hop is reached that does not understand  
> > decorated NAI then the packet will be consumed locally.
> >
> >
> >
> > Please see inline for more comments
> >
> > > -----Original Message-----
> > > From: jouni korhonen [mailto:jouni.nospam at gmail.com]
> > > Sent: March 3, 2009 5:44 PM
> > > To: Avi Lior
> > > Cc: Lionel.morand at orange-ftgroup.com; Mark Jones;
> > > tena at huawei.com; Hannes.Tschofenig at gmx.net; dime at ietf.org
> > > Subject: Re: Dime NAI Routing
> > >
> > > Hi Avi,
> > >
> > > Thanks for reading & commenting the I-D.
> > >
> > > On Mar 2, 2009, at 11:41 PM, Avi Lior wrote:
> > >
> > > > A couple of comments:
> > > >
> > > > 1)  The draft should mention something about the presence of
> > > > Destination-Host AVP.
> > > >
> > > > The rule for routing is that the Destination-Host AVP is
> > > not looked at
> > > > until the message reaches the terminal realm as determined by the
> > > > decorated NAI.
> > >
> > > Where you would suggest to include the clarifying text? In
> > > Section 4.2.?
> >
> > I don't know.  I will have to look at the draft. This is really a  
> > side issue and depends on the intent of the draft.
>
> Ok.
>
> > > > 2) I dont like the way Destination-Realm is being used.
> > > >
> > > > The draft states that the destination realm is updated on a
> > > hop by hop
> > > > basis together with the decorated NAI.
> > >
> > > I assume that is the only way to ensure the request message
> > > really goes through all wanted realms.
> >
> > Correct.  And in some cases NAI routing is going to be more  
> > important and in some cases it will be more important to make sure  
> > the message makes it all the way.
> >
> > > > If an intermediary is not compliant with the scheme
> > > presented by this
> > > > draft it will result in the intermediary consuming the
> > > message locally
> > > > - since the message contains the destination realm equal to
> > > > its realm.   Thus the message is not going to reach the  
> > > > destination.
> > >
> > > That is the reason why the I-D suggests only using the
> > > decoration stuff with a new application that is known to
> > > support this I-D. In that way legacy agents can be bypassed.
> >
> > Okay so here you are clear this is Application based routing.
>
> This is suggested/recommended only when there is no guarantee that  
> all agents implement the NAI routing. To my understanding all  
> Diameter routing is based on applications + realms anyway, so I  
> don't see the problem.
>
> > > > Instead, I propose that the destination realm should be
> > > always set to
> > > > the terminal realm, thus:
> > > >
> > > > Agents that are compliant with the draft will first look at
> > > the NAI to
> > > > determine whether the packet has reached the terminal realm
> > > or where
> > > > it should be routed next;
> > >
> > > Are you proposing to make the routing decision based on the
> > > User-Name (and ignore the Destination-Realm all together) in
> > > cases where 1) the agent supports this I-D and 2) the
> > > User-Name contains a decorated NAI?
> > > Once the decorated NAI would have been "consumed" the
> > > checking would be based on the Destination-Realm again..?
> >
> > Almost. In the case where you want to guarantee packet delivery  
> > irrespective of whether nodes are compliant with this draft, then  
> > you set the destination-realm to the final destination of the  
> > decorated NAI.  Agents that support your scheme would use the  
> > decorated NAI to determine how to route to the next hop.  Agents  
> > that don't support your scheme will use the destination-realm to  
> > determine how to route to the next hop (they will ignore the  
> > decorated NAI).
>
> Ok. That was close enough to my understanding ;) So, the route  
> decision would be:
>
> 1) case NAI routing supported:
>   route decision: User-Name + Application
>   if User-Name's @realm matches agent's own realm, precess the NAI
>
> 2) case normal RFC3588
>   route decision: Destination-Realm + Application
>   Modify: none
>
> right?
>
>
> > > > Agents that are not compatible with the draft will use the
> > > old rules
> > > > for routing and would route the message according to the
> > > destination-
> > > > realm only and thus the message will reach the final destintaion
> > > > albeit not necessarily according to the decorated NAI. But
> > > at least it
> > > > would work.
> > > >
> > > >
> > > > Did I miss anything?
> > >
> > > What happens if.. the route happens to have some
> > > non-compliant agents and when the request reaches its final
> > > end (e.g. according to the inter-connection architecture) the
> > > User-Name still has decorated NAI?
> > > Would the decorated NAI compliant server/proxy send to
> > > request back to some other realm pointed by the User-name?
> > > This would effectively cause a routing loop, right?
> > No. It may cause a loop but it wont be an infinite loop.  So it  
> > depends, in some cases I may be okay with have strange routing but  
> > I will at least get the packet there. So it depends what I want to  
> > achieve.
>
> There is no guarantee that the alternate route selected by the agent  
> that discovered the loop would result to any better outcome. The  
> alternate route could again route traffic back.
>
> Cheers,
> 	Jouni
>
> > > Cheers,
> > >       Jouni
> > >
> > >
> > >
> > > >
>
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime