Re: [Dime] Dime NAI Routing

[Avi Lior <avi at bridgewatersystems.com>]

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: lionel.morand at orange-ftgroup.com [lionel.morand at orange-ftgroup.com]
Sent: Monday, March 23, 2009 10:00 PM
To: jouni.nospam at gmail.com; Avi Lior
Cc: Mark Jones; dime at ietf.org
Subject: RE: [Dime] Dime NAI Routing

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 : dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] De
> la part de jouni korhonen
> Envoyé : jeudi 12 mars 2009 11:53
> À : Avi Lior
> Cc : Mark Jones; MORAND Lionel RD-CORE-ISS; dime at ietf.org
> 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.
>
> 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
>
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>