RE: [Dime] yet another way of achieving strict routing

["Tolga Asveren" <asveren at ulticom.com>]

Hi John,

One important point regarding B2BUA (or ALG or whatever we want to name it)
is that it does not require any changes to the existing protocol definition,
i.e. it is not violating on-the-wire aspects of RFC3588 AFAICS. Basically it
is not a protocol issue but an administrative/deployment issue whether one
wants to deploy it -and thus IETF can't do anything about it ;-) -.

>From security point of view, I guess it won't cause a practical problem for
most of the cases. I would think, the application level processing which
needs to be performed on such nodes -whether it be ALG or proxy- anyhow will
require inspection of AVPs and some preestablished trust relationship. It
could be the case that people want certain AVPs to be end-to-end secured,
but I don't think this will be majority of the cases and I agree that ALG
approach won't provide a satisfactory solution if that is required.

I think, it is worthwile to make people aware that this (ALG, B2BCS
[Back-to-Back-Client-Server]) is an option, if it suits their needs. If
mentioning of such functionality wouldn't be blessed by IETF because it
breaks end-to-end security (Actually there are different ways of seeing this
as well, from Diameter Base Protocol point of view, ALG is and endpoint,
well actually two endpoints and hence does not violate end-to-end security),
I hope this thread was informative enough for people (at least for me it
was).

   Thanks,
   Tolga


> -----Original Message-----
> From: john.loughney at nokia.com [mailto:john.loughney at nokia.com]
> Sent: Monday, July 10, 2006 9:15 AM
> To: asveren at ulticom.com; yohba at tari.toshiba.com
> Cc: dime at ietf.org
> Subject: RE: [Dime] yet another way of achieving strict routing
>
>
> Hi all,
>
> I basically side with Yoshihiro so far.  About Diameter "B2BUA"
> funtionality, this would be officially frowned upon in the IETF,
> as it does cause problems with security.  If we would bring back
> the end-to-end security for Diameter (CMS work), then this kind
> of deployment would be easier to digest.
>
> John
>
> >-----Original Message-----
> >From: ext Tolga Asveren [mailto:asveren at ulticom.com]
> >Sent: 06 July, 2006 15:58
> >To: Yoshihiro Ohba
> >Cc: dime at ietf.org
> >Subject: RE: [Dime] yet another way of achieving strict routing
> >
> >Hi Yoshihiro,
> >
> >Yes, it is analogical to a SIP B2BUA. Actually in my world of
> >ideas this is the definition of a proxy in the generic sense
> >-I am not speaking of SIP/Diameter proxies-: A proxy is an
> >entity, which acts on behalf of another entity. Proxy as
> >defined in SIP -or as defined in Diameter- is more a glorified
> >relay node, but I agree with you that the node I describe is
> >not the "proxy" defined in RFC3588. (Diameter proxy is more
> >similar to the concept of proxy in my mind because it has more
> >authority in terms of changing the contents of the message, so
> >I probably would classify it somewhere between relay and proxy)
> >
> >IMHO, this is not orthogonal to strict routing issue because
> >it is one way of dealing with scenarios presented as the
> >reason for strict routing.
> >Actually, if one considers the application logic running on
> >such nodes, it seems to me a reasonable solution but picking
> >one approach over another one is obviously an implementation decision.
> >
> >    Thanks,
> >    Tolga
> >
> >> -----Original Message-----
> >> From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> >> Sent: Thursday, July 06, 2006 4:02 PM
> >> To: Tolga Asveren
> >> Cc: Yoshihiro Ohba; Tony Zhang; dime at ietf.org
> >> Subject: Re: [Dime] yet another way of achieving strict routing
> >>
> >>
> >> Hi Tolga,
> >>
> >> Is the sceanario you described is an application layer gateway for
> >> (like SIP B2BUA)?  If so, we should not mix it up with a proxy and I
> >> believe it is orthogonal to the strict routing issue.
> >>
> >> Yoshihiro Ohba
> >>
> >>
> >> On Thu, Jul 06, 2006 at 01:55:48PM -0400, Tolga Asveren wrote:
> >> > O.K., now I got what you mean. And yes, this will be a problem
> >> unless B and
> >> > C work in a synchronized way, where they share state. I
> >think, this
> >> > they need to do anyhow, because they keep some application level
> >> state, otherwise
> >> > they wouldn't want to stay on the path. Basically, in the model
> >> I described,
> >> > B and C act as endnodes. If there are intermediaries, which don't
> >> > share state, I would expect them to abort the session after a
> >> failover -when they
> >> > receive messages for an unknown session-, because they can't
> >> perform their
> >> > application level processing regarding that session.
> >> >
> >> > 	Thanks,
> >> >       Tolga
> >> >
> >> > > -----Original Message-----
> >> > > From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> >> > > Sent: Thursday, July 06, 2006 1:59 PM
> >> > > To: Tolga Asveren
> >> > > Cc: Yoshihiro Ohba; Tony Zhang; dime at ietf.org
> >> > > Subject: Re: [Dime] yet another way of achieving strict routing
> >> > >
> >> > >
> >> > > On Thu, Jul 06, 2006 at 12:01:11PM -0400, Tolga Asveren wrote:
> >> > > > If the intermediary node uses the same End-to-End
> >identifier for
> >> > > > the original and retransmission request, this shouldn't be a
> >> problem. Server
> >> > > > would receive two requests with the same Origin-Host and
> >> > > End-to-End values
> >> > > > and could detect the duplicate.
> >> > >
> >> > > You are assuming that the two requests go through the same
> >> > > intermediary, which is not always true.  Retransmission can also
> >> > > happen at the original sender.
> >> > >
> >> > >   +-----B----+
> >> > >  /            \
> >> > > A              D
> >> > >  \            /
> >> > >   +-----C----+
> >> > >
> >> > > Assume that the orignial request is forwarded A->B->D.
> >> > >
> >> > > If failover happens at A, A may retransmit the request to a
> >> > > different path, say A->C->D.
> >> > >
> >> > > If B modifies the Origin-Host and End-to-End values of the
> >> > > original request, the original and retransmitted requests will
> >> > > have different Origin-Host or End-to-End values.  This is the
> >> > > problem I was mentioning.
> >> > >
> >> > > Yoshihiro Ohba
> >> > >
> >> > >
> >> > >
> >> > > > > -----Original Message-----
> >> > > > > From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> >> > > > > Sent: Thursday, July 06, 2006 12:17 PM
> >> > > > > To: Tolga Asveren
> >> > > > > Cc: Yoshihiro Ohba; Tony Zhang; dime at ietf.org
> >> > > > > Subject: Re: [Dime] yet another way of achieving strict
> >> > > > > routing
> >> > > > >
> >> > > > >
> >> > > > > Allowing a Diameter node to creates a request with modifying
> >> > > > > End-to-End Identifier and Origin-Host AVP can break
> >> interoperability,
> >> > > > > because the server cannot distinguish the original
> >request and
> >> > > > > the modified request.  As a result, the server will process
> >> > > > > the two requests differently and generate two different
> >> > > > > answers
> >> as oppose to
> >> > > > > the original requester's expectation that only one
> >> request should be
> >> > > > > processed by a given server and that no multiple
> >> > > > > non-duplicated answers are received for the same request.
> >> > > > >
> >> > > > > Yoshihiro Ohba
> >> > > > >
> >> > > > > On Thu, Jul 06, 2006 at 10:48:06AM -0400, Tolga
> >Asveren wrote:
> >> > > > > > Hi Yoshihiro,
> >> > > > > >
> >> > > > > > If the proxy creates a corresponding but new request for a
> >> > > request it is
> >> > > > > > proxying, I don't see why there should be a problem from
> >> > > > > duplicate detection
> >> > > > > > point of view. In that case, there are two Diameter
> >> > > > > > signaling
> >> > > > > relationships,
> >> > > > > > one between the client and the proxy and the other one
> >> > > > > > between
> >> > > > > the proxy and
> >> > > > > > the server, i.e. client sees proxy as server and server
> >> > > sees proxy as
> >> > > > > > client.
> >> > > > > >
> >> > > > > > OTOH, one could argue whether that type of behavior is
> >> > > > > overlapping with the
> >> > > > > > definition of proxy in RFC3588, but I believe one can mix
> >> > > > > > and
> >> > > > > match any type
> >> > > > > > of functionality in any node as long as interoperability is
> >> > > not broken.
> >> > > > > >
> >> > > > > >    Thanks,
> >> > > > > >    Tolga
> >> > > > > >
> >> > > > > >
> >> > > > > > > -----Original Message-----
> >> > > > > > > From: Yoshihiro Ohba [mailto:yohba at tari.toshiba.com]
> >> > > > > > > Sent: Thursday, July 06, 2006 9:44 AM
> >> > > > > > > To: Tolga Asveren
> >> > > > > > > Cc: Tony Zhang; dime at ietf.org
> >> > > > > > > Subject: Re: [Dime] yet another way of achieving
> >> strict routing
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > RFC 3588 has explicit text that prohibits replacing
> >> the End-to-End
> >> > > > > > > Identifier:
> >> > > > > > >
> >> > > > > > >   "The End-to-End Identifier MUST NOT be modified by
> >> > > Diameter agents
> >> > > > > > >   of any kind."
> >> > > > > > >
> >> > > > > > > Note: if the proxy replaces the End-to-End
> >Identifier AVP,
> >> > > > > > > the ultimate receiver of the request message will not
> >> able to detect a
> >> > > > > > > duplicate request if the original request is routed
> >> via the proxy
> >> > > > > > > while a dup of the original request is not routed via the
> >> > > proxy.  For
> >> > > > > > > the same reason, Origin-Host AVP should not be modified
> >> > > by the proxy.
> >> > > > > > > (RFC 3588 has explicit text that prohibits modification
> >> > > of Origin-Host
> >> > > > > > > AVP by relay agents in Section 6.3, but the text should
> >> > > be revised to
> >> > > > > > > prohibit modification of Origin-Host AVP by any Diameter
> >> > > agents of any
> >> > > > > > > kind.)
> >> > > > > > >
> >> > > > > > > Yoshihiro Ohba
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Wed, Jul 05, 2006 at 10:15:29AM -0400, Tolga
> >Asveren wrote:
> >> > > > > > > > One quick note on duplicat detection in the setup we
> >> > > are discussing:
> >> > > > > > > > Proxy probably doesn't need to provide duplicate
> >> detection, as
> >> > > > > > > long as it
> >> > > > > > > > generates a new request for each request it is
> >proxying.
> >> > > > > the new request
> >> > > > > > > > would have a new End-to-ed Identifier assigned
> >by the proxy.
> >> > > > > > > >
> >> > > > > > > >     Thanks,
> >> > > > > > > >       Tolga
> >> > > > > > > >
> >> > > > > > > > > -----Original Message-----
> >> > > > > > > > > From: Tolga Asveren [mailto:asveren at ulticom.com]
> >> > > > > > > > > Sent: Wednesday, July 05, 2006 9:01 AM
> >> > > > > > > > > To: Tony Zhang; dime at ietf.org
> >> > > > > > > > > Subject: RE: [Dime] yet another way of achieving
> >> > > strict routing
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > Hi Tony,
> >> > > > > > > > >
> >> > > > > > > > > > -----Original Message-----
> >> > > > > > > > > > From: Tony Zhang [mailto:zhangtao_hw at huawei.com]
> >> > > > > > > > > > Sent: Sunday, July 02, 2006 10:29 PM
> >> > > > > > > > > > To: Tolga Asveren; dime at ietf.org
> >> > > > > > > > > > Subject: Re: [Dime] yet another way of achieving
> >> > > strict routing
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > Hi Tolga:
> >> > > > > > > > > >    (1) Some Request in session are sent by
> >> > > server.so should each
> >> > > > > > > > > > proxy repalce first request
> >> > > Origin-Host/Origin-Realm  then maybe
> >> > > > > > > > > > will achieve this.
> >> > > > > > > > > [TOLGA]That is really a good point. The solution
> >> is probably
> >> > > > > > > real proxying
> >> > > > > > > > > of the requests: Both Origin/Destination AVP
> >> > > > > > > > > information
> >> > > > > needs to be
> >> > > > > > > > > replaced with the identity of the proxy entity. In
> >> > > > > > > > > that
> >> > > > > > > model, from client
> >> > > > > > > > > point of view, it is the proxy which provides the
> >> > > > > > > > > service,
> >> > > > > > > and this is my
> >> > > > > > > > > understanding of a proxy in the generic sense. This
> >> > > would mean,
> >> > > > > > > > > proxies need
> >> > > > > > > > > to provide duplicate detection as well because it
> >> relies on
> >> > > > > > > > > Origin-Host AVP
> >> > > > > > > > > value, but that IMO is logical considering that proxy
> >> > > > > acts as a node
> >> > > > > > > > > providing a service.
> >> > > > > > > > > >    (2)if client send request to one realm,but
> >> > > another realm give
> >> > > > > > > > > > answer,maybe will confusion.
> >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from protocol
> >> > > > > > > mechanics point of
> >> > > > > > > > > view.
> >> > > > > > > > > > Thanks
> >> > > > > > > > > > Tony
> >> > > > > > > > > > ----- Original Message -----
> >> > > > > > > > > > From: "Tolga Asveren" <asveren at ulticom.com>
> >> > > > > > > > > > To: <dime at ietf.org>
> >> > > > > > > > > > Sent: Saturday, July 01, 2006 5:08 AM
> >> > > > > > > > > > Subject: [Dime] yet another way of achieving
> >> strict routing
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > > While studying the mechanics of achiveing strict
> >> > > routing in
> >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the following
> >> > > > > > > > > > > came
> >> > > > > to my mind:
> >> > > > > > > > > > >
> >> > > > > > > > > > > 1) Requests are sent by client regularly
> >> > > > > > > > > > > 2) Stateless intermediaries just relay
> >the message
> >> > > > > > > > > > > 3) If an intermediary wants to stay in the path
> >> > > for a session,
> >> > > > > > > > > > it does the
> >> > > > > > > > > > > following with the messages for that session:
> >> > > > > > > > > > > i- For the first answer, it saves the
> >> > > Origin-Host/Origin-Realm
> >> > > > > > > > > > AVP values
> >> > > > > > > > > > > in the message and replaces them with its own
> >> > > > > Host/Realm values.
> >> > > > > > > > > > > ii- Subsequent requests received by this
> >> > > > > > > > > > > intermediary
> >> > > > > > > will have its
> >> > > > > > > > > > > Host/Realm value in
> >> > > Destination-Host/Destination-Realm AVPs of
> >> > > > > > > > > > the request.
> >> > > > > > > > > > > They are replaced with the values stored in i-.
> >> > > > > > > > > > >
> >> > > > > > > > > > > Considering that proxies which want to
> >stay on the
> >> > > > > path will be
> >> > > > > > > > > > stateful, 3)
> >> > > > > > > > > > > shouldn't be a problem.
> >> > > > > > > > > > >
> >> > > > > > > > > > > This is very similar to what is explained in the
> >> > > draft, except
> >> > > > > > > > > > the state is
> >> > > > > > > > > > > kept in proxies rather than in the message.
> >> > > > > > > > > > >
> >> > > > > > > > > > >    Thanks,
> >> > > > > > > > > > >    Tolga
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > > _______________________________________________
> >> > > > > > > > > > > DiME mailing list
> >> > > > > > > > > > > DiME at ietf.org
> >> > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> >> > > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > _______________________________________________
> >> > > > > > > > > DiME mailing list
> >> > > > > > > > > DiME at ietf.org
> >> > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > _______________________________________________
> >> > > > > > > > DiME mailing list
> >> > > > > > > > DiME at ietf.org
> >> > > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> >> > > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > >
> >> > > >
> >> >
> >> >
> >
> >
> >_______________________________________________
> >DiME mailing list
> >DiME at ietf.org
> >https://www1.ietf.org/mailman/listinfo/dime
> >


_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime