Subject: Re: [Dime] yet another way of achieving strict routing

From: Victor Fajardo <[email-masked]>
Date: Sat, 01 Jul 2006 14:24:03 -0400

Hi Tolga,

Theres probably a multitude of ways to achieve strict routing and most 
of them have more or less the same efficiency/performance. However, the 
proposals in the draft attempts to follow a well know, well understood 
mechanism that already exist in other protocols (IP SSR, SIP 
route-record etc.) which will hopefully lead to a clearer and more 
coherent way of doing things. It is also a bit more beneficial to 
separate route records into it's own set of avps to aid in debugging 
routing problems when using such scheme and it does not have to 
introduce duality in the purpose or meaning of existing avps such as 
origin-host which may or may not be used by the application to indicate 
the true endpoint of the message.

many thanks,
victor
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>   

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Tony Zhang <[email-masked]>
Date: Mon, 03 Jul 2006 10:29:10 +0800

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. 
   (2)if client send request to one realm,but another realm give answer,maybe will confusion.
Thanks
Tony

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 5 Jul 2006 08:24:56 -0400

Hi Victor,

I agree that there may be different ways of achieving strict routing but I
also believe any draft/RFC -at least after they are an official WG item -
should give a realistic and balanced view of the issues addressed. IMHO, it
is a good idea to list all of the meaningful solutions we can think of as a
guideline for people. To me, any solution, which requires only local
processing within boundaries of the existing procotol definition is very
valuable as well.

Just my two cents...

   Thanks,
   Tolga

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Saturday, July 01, 2006 2:24 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Dime] yet another way of achieving strict routing
>
>
> Hi Tolga,
>

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 5 Jul 2006 09:01:23 -0400

Hi Tony,

> From: Tony Zhang [mailto:[email-masked]]
> Sent: Sunday, July 02, 2006 10:29 PM
> To: Tolga Asveren; [email-masked]
>    (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.
> answer,maybe will confusion.
[TOLGA]That IMHO shouldn't be an issue from protocol mechanics point of
view.

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 5 Jul 2006 10:15:29 -0400

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

> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Wednesday, July 05, 2006 9:01 AM
> To: Tony Zhang; [email-masked]
> Subject: RE: [Dime] yet another way of achieving strict routing
>
>
> Hi Tony,
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 05 Jul 2006 11:15:27 -0400

Hi Tolga,

This is true and maybe we should have text that represents this 
especially in this case where there could be multiple application 
specific solutions.

regards,
victor
>>> 3) If an intermediary wants to stay in the path for a session,
>>>       
>> it does the
>>     
>>> 	i- For the first answer, it saves the
>>>       
>> Origin-Host/Origin-Realm AVP values
>>     
>>> Host/Realm value in Destination-Host/Destination-Realm AVPs of
>>>       
>> the request.
>>     
>>> 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
>>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 06 Jul 2006 09:43:31 -0400

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Jul 2006 10:48:06 -0400

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

> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Thursday, July 06, 2006 9:44 AM
> To: Tolga Asveren
> Cc: Tony Zhang; [email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 06 Jul 2006 12:16:37 -0400

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Jul 2006 12:01:11 -0400

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.
> Sent: Thursday, July 06, 2006 12:17 PM
> To: Tolga Asveren
> Cc: Yoshihiro Ohba; Tony Zhang; [email-masked]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 06 Jul 2006 13:58:36 -0400

> 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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Jul 2006 13:55:48 -0400

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

> Sent: Thursday, July 06, 2006 1:59 PM
> To: Tolga Asveren
> > > > > > > understanding of a proxy in the generic sense. This
> would mean,
> > > > > > > proxies need
> > > > > > > >    (2)if client send request to one realm,but
> another realm give
> > > > > > > > answer,maybe will confusion.
> > > > > > > > > Host/Realm value in
> Destination-Host/Destination-Realm AVPs of
> > > > > > > > the request.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 06 Jul 2006 16:02:18 -0400

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 6 Jul 2006 15:58:11 -0400

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

> Sent: Thursday, July 06, 2006 4:02 PM
> To: Tolga Asveren
> > > > > > > > Proxy probably doesn't need to provide duplicate
> detection, as
> > > > > > > long as it
> > > > > > > > > [TOLGA]That is really a good point. The solution
> is probably
> > > > > > > real proxying
> > > > > > > > > to provide duplicate detection as well because it
> relies on
> > > > > > > > > Origin-Host AVP

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 7 Jul 2006 00:13:20 -0400

Hi Tolga,

On Thu, Jul 06, 2006 at 03:58:11PM -0400, Tolga Asveren wrote:
(snip)
> is obviously an implementation decision.

I am not sure if application layer gateway provides strict routing.  

A------B------C-----E
        \          /
         +----D---+

Assume that B is an application layer gateway.  C and D may be a proxy
or an application layer gateway.  A can forward a request to B, but
how can A specify that the request should then forwarded to C and not
to D?

Regards,
Yoshihiro Ohba

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 7 Jul 2006 09:12:59 -0400

Hi Yoshihiro,

(I will call the node we are discussing ALG for lack of better terminology
right now)
All nodes, which want to stay on the path -for some application layer
processing- need to be ALGs.

In the example you draw below, if there is a need that messages follow the
path A->B->C, this can be achieved through configuration on A and B. A
should know that for App=X, Realm=a.net, messages need to be sent to B -B
could be one of the many possible adjacent nodes, that it stays always on
the path is guranteed by B itself-, similarly B need to know through
configuration that for App=X, Realm=a.net, messages need to be sent to
C -again C is probably one of the many in the list-.

Basically it will be intermediaries which decide to stay on the path. I
don't know whether there are cases where the client needs to decide for all
nodes to be traversed but to my understanding, the real life examples
discussed so far do not require that type of behavior.

BTW, let me reemphasize that I think the ALG approach is only one of the
possible solutions, I am not claiming it should be "the solution".

	Thanks,
      Tolga

> Sent: Friday, July 07, 2006 12:13 AM
> To: Tolga Asveren

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 07 Jul 2006 10:32:49 -0400

Hi,

It may just be a matter of terminology (though I don't have a strong 
opinion on this) but to me 'strict source routing' means that the real 
end-point destination is the true consumer of the original message. To 
me, an ALG is half server, half client. The server half consumes the 
original message and generates a NEW message towards the end-point.

my two cents ...
victor
>>> IMHO, this is not orthogonal to strict routing issue because it
>>>       
>> is one way
>>     
>>> 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
>>

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 7 Jul 2006 16:12:17 -0400

Hi Victor,

> Sent: Friday, July 07, 2006 10:33 AM
> To: Tolga Asveren
> Cc: Yoshihiro Ohba; [email-masked]
[TOLGA]I agree with you that from functionality point of view an ALG is not
equivalent to a proxy which supports the Diameter strict routing extension,
both of them can provide a working solution for certain configurations
though. Probably I better called this thread "yet another way of staying in
the message path".

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 17:03:07 +0300

Tolga,

Understood.  What I am cautioning against is when provider C
who is running the Diameter ALG is between two providers - 
A & B.  As it is possible that C could modify Diameter packets
without A & B knowing it, potentially mis-representing the actual
traffic.  During the initial standardization of Diameter, one
AD particularly was against proxy mode, for this behavior.
end-to-end message encryption is one way to to get around this
behavior, so you don't encrypt the transport, just the message
contents.

If this is a non-issue for users deploying Diameter, then perhaps
it is a non-issue.

John

>From: ext Tolga Asveren [mailto:[email-masked]] 
>Sent: 10 July, 2006 09:27
>To: Loughney John (Nokia-NRC/Helsinki); [email-masked]
>Cc: [email-masked]
>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
>
>
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Monday, July 10, 2006 9:15 AM
>> To: [email-masked]; [email-masked]
>> Cc: [email-masked]
>> 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
>>
>> >From: ext Tolga Asveren [mailto:[email-masked]]
>> >Sent: 06 July, 2006 15:58
>> >To: Yoshihiro Ohba
>> >Cc: [email-masked]
>> >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
>> >
>> >> (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
>> >>
>> >>
>> >> > 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
>> >> > 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
>> >> > > > If the intermediary node uses the same End-to-End
>> >identifier for
>> >> > > > the original and retransmission request, this shouldn't be a
>> >> problem. Server
>> >> > > intermediary, which is not always true.  Retransmission can 
>> >> > > also happen at the original sender.
>> >> > >
>> >> > >   +-----B----+
>> >> > >  /            \
>> >> > > A              D
>> >> > >  \            /
>> >> > >   +-----C----+
>> >> > >
>> >> > > 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
>> >> > >
>> >> > >
>> >> > >
>> >> > > > > 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
>> >> > > > > processed by a given server and that no multiple 
>> >> > > > > non-duplicated answers are received for the same request.
>> >> > > > >
>> >> > > > > Yoshihiro Ohba
>> >> > > > >
>> >> > > > > > If the proxy creates a corresponding but new 
>request for 
>> >> > > > > > a
>> >> > > request it is
>> >> > > > > > 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
>> >> > > > > > 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
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > > Note: if the proxy replaces the End-to-End
>> >Identifier AVP,
>> >> > > > > > > the ultimate receiver of the request message will not
>> >> able to detect a
>> >> > > > > > > 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
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > > generates a new request for each request it is
>> >proxying.
>> >> > > > > the new request
>> >> > > > > > > > > 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
>> >> > > > > > > > > value, but that IMO is logical considering that 
>> >> > > > > > > > > proxy
>> >> > > > > acts as a node
>> >> > > > > > > > > providing a service.
>> >> > > > > > > > > [TOLGA]That IMHO shouldn't be an issue from 
>> >> > > > > > > > > protocol
>> >> > > > > > > mechanics point of
>> >> > > > > > > > > view.
>> >> > > > > > > > > > Thanks
>> >> > > > > > > > > > Tony
>> >> > > > > > > > > > > While studying the mechanics of achiveing 
>> >> > > > > > > > > > > strict
>> >> > > routing in
>> >> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the 
>following 
>> >> > > > > > > > > > > came
>> >> > > > > to my mind:
>> >> > > > > > > > > > >
>> >> > > > > > > > > > > 3) If an intermediary wants to stay 
>in the path
>> >> > > for a session,
>> >> > > > > > > > > > it does the
>> >> > > > > > > > > > > ii- Subsequent requests received by this 
>> >> > > > > > > > > > > intermediary
>> >> > > > > > > will have its
>> >> > > > > > > > > > > Host/Realm value in
>> >> > > > > > > > > > > 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
>> >> > > > > > > > > > > DiME mailing list [email-masked]

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 10 Jul 2006 10:03:40 -0400

John,

I agree that this is a valid concern, which may be applicable for certain
configurations. At the end, it will be operators, which decide for their own
security needs and they will use necessary tools to achieve it.

One more point regarding this issue, in terms of how that type of security
may be provided when using an ALG:
Actually it is probably no more different than what a proxy would do. Let's
say some AVPs are end-to-end encrypted. Those will be directly included in
the new message ALG is generating against the server as is, without
encrytion/decryption. ALG wouldn't need to decrypt them because they
wouldn't be necessary for the application logic running on the ALG.

     Thanks,
     Tolga

> Sent: Monday, July 10, 2006 10:03 AM

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 10 Jul 2006 11:31:56 -0400

Tolga,

I think you are still mixing up ALG and proxy.  The ALG is a really
the termination point of Diameter end-to-end communication, and thus
all encrypted AVPs need to be decrypted by the ALG and passed to the
application.

Yoshihiro Ohba

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 10 Jul 2006 11:54:39 -0400

Yoshihiro,

Afterall, ALG is some piece of software, which will do, whatevery you want
it to do. The end-to-end security aware ALG could look just into the AVPs it
needs to look for the processing it needs to perform and can leave
end-to-end encrypted AVPs as is. I don't see why it must decrypt all those
AVPs.

    Thanks,
    Tolga

> Sent: Monday, July 10, 2006 11:32 AM
> To: Tolga Asveren
> Cc: [email-masked]; [email-masked]; [email-masked]
> > > >> >> > they wouldn't want to stay on the path. Basically, in
> the model
> > > >> >> I described,
> > > >> >> > > > > > proxying, I don't see why there should be a
> problem from
> > > >> >> > > > > duplicate detection
> > > >> >> > > > > > the server, i.e. client sees proxy as server
> and server
> > > >> >> > > sees proxy as
> > > >> >> > > > > > client.
> > > >> >> > > > > >
> > > >> >> > > > > > > > One quick note on duplicat detection in
> the setup we
> > > >> >> > > are discussing:
> > > >> >> > > > > > > > > > Subject: Re: [Dime] yet another way
> of achieving
> > > >> >> > > strict routing
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > >
> > > >> >> > > > > > > > > > Hi Tolga:
> > > >> >> > > > > > > > > > > in the message and replaces them
> with its own
> > > >> >> > > > > Host/Realm values.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 10 Jul 2006 13:26:49 -0400

I guess you are assuming Diameter-application layer encryption which
works across DIameter ALG.  That would need a new Diameter application
with its own security that can work across ALG.  I'd suggest not
discuss it unless you really want to standardize it.  I feel we are not 
doing productive discusion here.

Yoshihiro Ohba

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 10 Jul 2006 13:08:19 -0400

I am not assuming a specific encryption type. My only assumption is if a
proxy can copy certain encrypted AVPs as is, an ALG can do it as well. I
don't think this requires to define something specifically for ALG case.

   Thanks,
   Tolga

> Sent: Monday, July 10, 2006 1:27 PM
> To: Tolga Asveren
> Cc: Yoshihiro Ohba; [email-masked]; [email-masked]
> > > > > >> >> > O.K., now I got what you mean. And yes, this will
> be a problem
> > > > > >> >> unless B and
> > > > > >> >> > receive messages for an unknown session-, because
> they can't
> > > > > >> >> perform their
> > > > > >> >> > > > would receive two requests with the same
> Origin-Host and
> > > > > >> >> > > End-to-End values
> > > > > >> >> > > > > Subject: Re: [Dime] yet another way of
> achieving strict
> > > > > >> >> > > > > routing
> > > > > >> >> > > > >
> > > > > >> >> > > > >
> > > > > >> >> > > > > > OTOH, one could argue whether that type
> of behavior is
> > > > > >> >> > > > > overlapping with the
> > > > > >> >> > > > > > > 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."
> > > > > >> >> > > > > > >
> > > > > >> >> > > > > > > duplicate request if the original
> request is routed
> > > > > >> >> via the proxy
> > > > > >> >> > > > > > > > > Subject: RE: [Dime] yet another way
> of achieving
> > > > > >> >> > > strict routing
> > > > > >> >> > > > > > > > >
> > > > > >> >> > > > > > > > >
> > > > > >> >> > > > > > > > > Hi Tony,
> > > > > >> >> > > > > > > > >
> > > > > >> >> > > > > > > > > > Subject: [Dime] yet another way
> of achieving
> > > > > >> >> strict routing
> > > > > >> >> > > > > > > > > >
> > > > > >> >> > > > > > > > > >

---

From: <[email-masked]>
Date: Mon, 10 Jul 2006 16:15:02 +0300

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

>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.
>such nodes, it seems to me a reasonable solution but picking 
>one approach over another one is obviously an implementation decision.
>
>    Thanks,
>    Tolga
>
>> > B and C act as endnodes. If there are intermediaries, which don't 
>> > > original request, the original and retransmitted requests will 
>> > > > > the modified request.  As a result, the server will process 
>> > > > > > definition of proxy in RFC3588, but I believe one can mix 
>> > > > > > and
>> > > > > match any type
>> > > > > > > > > replaced with the identity of the proxy entity. In 
>> > > > > > > > > that
>> > > > > > > model, from client
>> > > > > > > > > > > draft-tsou-dime-base-routing-ext, the following 
>> > > > > > > > > > > came
>> > > > > to my mind:
>> > > > > > > > > > >

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 10 Jul 2006 09:26:42 -0400

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