Subject: [Dime] Dime NAI Routing

From: Avi Lior <[email-masked]>
Date: Mon, 2 Mar 2009 16:41:28 -0500

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.

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.

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.

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;

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?

---

From: jouni korhonen <[email-masked]>
Date: Wed, 4 Mar 2009 00:44:25 +0200

Hi Avi,

Thanks for reading & commenting the I-D.

On Mar 2, 2009, at 11:41 PM, Avi Lior wrote:

> 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.?

> 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.

> 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.

> 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..?

> 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?

Cheers,
	Jouni

---

From: Avi Lior <[email-masked]>
Date: Tue, 10 Mar 2009 09:56:50 -0400

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.

But in responses I get, I get the feeling that the intent is really to have an Application based routing scheme using NAI.

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.

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.

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.

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:[email-masked]] 
> Sent: March 3, 2009 5:44 PM
> To: Avi Lior
> Cc: [email-masked]; Mark Jones; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Dime NAI Routing
> 
> Hi Avi,
> 
> > 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.
> 

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.

> > 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
> 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.

> >
> > 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).

> > 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.

---

From: jouni <[email-masked]>
Date: Wed, 11 Mar 2009 00:38:03 +0200

Hi Avi,

Thanks for the valuable input. See some comments inline.

On Mar 10, 2009, at 3:56 PM, Avi Lior wrote:

> 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.
>

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.

> 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.
>
>
>
> 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.

> 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.
>
>>

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.

> 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?

> 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

---

From: jouni korhonen <[email-masked]>
Date: Thu, 12 Mar 2009 12:53:23 +0200

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:

> 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.
>
>
>>
>> so we should stop debating that.  And actually in this case what  
>> you are doing is fine and you are probably there.
>>
> 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.
>
> agent MAY try an alternate route.. which would result another  
> routing loop. I see no way out of this.
>
>>
>>
>> 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.
>>
>>
>>
> 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.
>
>>
>>>>
>> 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.
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: <[email-masked]>
Date: Tue, 24 Mar 2009 03:00:18 +0100

Simple question:

All the decorated NAI handling described in the draft is based on the fact that there are "pre-existing" AAA roaming agreements between partners, established long before the first access request for a given user.

Could we just assume that all the partners belonging to AAA roaming agreements (and used by the UE to construct the Decorated NAI) MUST support the NAI Decoration?
If one of them doesn't support the NAI decoration, the handling of the request will fail but, in that case, this network should not be part of the roaming agreements. That is, "MUST" is a must if you want to be part of the game.

What we are saying here is that something could be wrong if someone does bad things. However, the basic principle of roaming agreements is that everyone plays the same game, with the rules, with the same part.

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de jouni korhonen
> Envoyé : jeudi 12 mars 2009 11:53
> À : Avi Lior
> Cc : Mark Jones; MORAND Lionel RD-CORE-ISS; [email-masked]
> Objet : Re: [Dime] Dime NAI Routing
> 
> 
> 
> 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.
> 
> 2) Some intermediates do not support NAI decoration, the 
> destination Diameter server
>     - 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
>     - 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
> 5) Some intermediates do not support NAI decoration, the 
> destination Diameter server
>       routing decision still based on 
> Destination-Realm+Application-id as
> 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
> 6) NAIavi probably requires more code changes in the existing 
> rfc3588 code base.
>     This could be a theoretical disadvantage though. I cannot 
> really judge
> >> 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.
> >
> >> 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.
> >>
> >> realm routing.  As you point out you get looping but its 
> not infinite 
> >> looping.  At least the message would get to the final destination.
> >
> >>> Where you would suggest to include the clarifying text? 
> In Section 
> >>> 4.2.?
> >>
> >> 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.
> >>
> >>>

---

From: Avi Lior <[email-masked]>
Date: Mon, 23 Mar 2009 22:12:28 -0400

Okay by that logic then no routing loops will occur and thus the correct approach is to use decorated NAI and still setting the destination realm to the final realm.

Since everyone will play by the same game, the intermediaries would use the NAI to route and not the destination realm.

Why then do we have to modify the destination-realm on a hop by hop basis.  That makes no sense.

________________________________________
From: [email-masked] [[email-masked]]
Sent: Monday, March 23, 2009 10:00 PM
To: [email-masked]; Avi Lior
Cc: Mark Jones; [email-masked]
Subject: RE: [Dime] Dime NAI Routing

Simple question:

Lionel

---

From: Ravi <[email-masked]>
Date: Sun, 29 Mar 2009 20:52:58 +0530

These are my views after going through the NAI draft
1) As pointed out by Avi Lior -  Modifying the destination-realm on a hop by
hop basis is not required. IMO, the destination-realm AVP should reflect the
actual destination(and not the intermediate destination), the request is
supposed to be routed to.

2) IMO, in its current form the draft is suggesting only one mechanism to
achieve "force routing of messages to the home realm through a predefined
list of realms". However, there are other methods of achieving the same
purpose like using another AVP called Realm-Path AVP which is added by the
client before sending the request. If we use a separate AVP for this purpose
then there would be a clear differentiation between Routing AVPs and
non-Routing AVPs.
       In the draft, the user-name AVP is used as a routing AVP by all the
proxies in the path of the request whereas the server uses it as a
non-Routing AVP (for authorization)

Ravi

On Tue, Mar 24, 2009 at 7:42 AM, Avi Lior <[email-masked]>wrote:

> Okay by that logic then no routing loops will occur and thus the correct
> approach is to use decorated NAI and still setting the destination realm to
> the final realm.
>
> Since everyone will play by the same game, the intermediaries would use the
> NAI to route and not the destination realm.
>
> All the decorated NAI handling described in the draft is based on the fact
> that there are "pre-existing" AAA roaming agreements between partners,
> established long before the first access request for a given user.
>
> Could we just assume that all the partners belonging to AAA roaming
> agreements (and used by the UE to construct the Decorated NAI) MUST support
> the NAI Decoration?
> If one of them doesn't support the NAI decoration, the handling of the
> request will fail but, in that case, this network should not be part of the
> roaming agreements. That is, "MUST" is a must if you want to be part of the
> game.
>
> What we are saying here is that something could be wrong if someone does
> bad things. However, the basic principle of roaming agreements is that
> everyone plays the same game, with the rules, with the same part.
>
> Lionel
>

---

From: jouni korhonen <[email-masked]>
Date: Mon, 30 Mar 2009 00:55:26 +0300

Hi Ravi,

Thanks for reading & commenting the draft. See my comments inline.

On Mar 29, 2009, at 6:22 PM, Ravi wrote:

> 1) As pointed out by Avi Lior -  Modifying the destination-realm on  
> a hop by hop basis is not required. IMO, the destination-realm AVP  
> should reflect the actual destination(and not the intermediate  
> destination), the request is supposed to be routed to.

We had some discussion on this during the Dime meeting. It seems that  
if one doesn't modify destination-realm on each hop, preventing  
routing loops become somewhat ugly. It looks like the only solid  
approach is requiring a new application and handling the NAI routing  
on the application level. And if new applications are involved then  
destination-realm more or less has to be modified on each realm.  
Otherwise, making sure that a proxy at each realm actually forwards  
the request to the application level handling is not that obvious.

>
> 2) IMO, in its current form the draft is suggesting only one  
> mechanism to achieve "force routing of messages to the home realm  
> through a predefined list of realms". However, there are other  
> methods of achieving the same purpose like using another AVP called  
> Realm-Path AVP which is added by the client before sending the  
> request. If we use a separate AVP for this purpose then there would  
> be a clear differentiation between Routing AVPs and non-Routing AVPs.

The draft tries to align Diameter with current practices and existing  
specs that actually assume Diameter supports NAI routing.

>        In the draft, the user-name AVP is used as a routing AVP by  
> all the proxies in the path of the request whereas the server uses  
> it as a non-Routing AVP (for authorization)

This is an unfortunate side effect. Partly because of this reason, one  
would like to make sure the intermediating proxies have actually  
"consumed" the whole decorated NAI. Otherwise the receiving server  
might get confused if the user-name still contains a decorated NAI.

Cheers,
	Jouni

>
> Ravi
>
> On Tue, Mar 24, 2009 at 7:42 AM, Avi Lior  
> <[email-masked]> wrote:
> Okay by that logic then no routing loops will occur and thus the  
> correct approach is to use decorated NAI and still setting the  
> destination realm to the final realm.
>
> Since everyone will play by the same game, the intermediaries would  
> use the NAI to route and not the destination realm.
>
> All the decorated NAI handling described in the draft is based on  
> the fact that there are "pre-existing" AAA roaming agreements  
> between partners, established long before the first access request  
> for a given user.
>
> agreements (and used by the UE to construct the Decorated NAI) MUST  
> support the NAI Decoration?
> If one of them doesn't support the NAI decoration, the handling of  
> the request will fail but, in that case, this network should not be  
> part of the roaming agreements. That is, "MUST" is a must if you  
> want to be part of the game.
>
> What we are saying here is that something could be wrong if someone  
> does bad things. However, the basic principle of roaming agreements  
> is that everyone plays the same game, with the rules, with the same  
> part.
>
> Lionel
>
> decoration