Subject: [Sipping] 3GPP Hiding requirements

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 20 Dec 2001 14:37:58 +0200

Hi:

I would like to start a discussion on the hiding requirements (requirement 6.12) listed in draft-garcia-sipping-3gpp-reqs-02.txt

The requirement reads: A network operator need not be required to reveal the internal network structure to another network (in Via, Route, or other headers) that may contain indication of the number of SIP proxies, domain name of the SIP proxies, capabilities of the SIP proxies or capacity of the network. Association of the node names of the same type of entity and their capabilities and the number of nodes may be kept private within an operator's network. However disclosure of the internal architecture must not be prevented on a per agreement basis.

Basically, the requirement is about not leaking information that may give business intelligence to competitors, based on the number and name of proxies, application servers, etc.

In order to support this requirement, 3GPP has the concept of a "hiding proxy". We can see this element as a SIP proxy located at the edge of the network. This is the ingress point of signaling to a network (e.g., result of a DNS SRV query). It may be also the egress point (kind of outbound proxy).

The hiding proxy may tokenize the contents of a few headers (Via, Route, Record-Route, etc), so that the contents are not readable to SIP proxies outside the network.

Although in draft-garcia-sipping-3gpp-reqs-02.txt we say that "We believe that the requirements in this section are met by the current SIP protocol [3]", I must say that this sentence will go away in the next version of the draft. I think we need to do something else to support this requirement.

The requirements is difficult to fulfill if we don't want to loose another capability of SIP: the ability of detecting spirals and loops. Loops are of particular interest, as it carries an error condition or configuration error somewhere in the network.

Having said that, I would like to discuss a possible solution to fulfill the hiding requirement without loosing the loop/spiral detection capability.

Let's assume the following preconditions:
- All ingress and egress SIP servers in the network share the same "tokenization/detokenization" algorithm.
- When a message reaches the egress SIP server, it tokenizes those headers that are needed. The result is a tokenized string that reflects a list of contiguous SIP proxies or AS within the same network (think of a Via header with a list of proxies).
- The egress SIP server also adds an indication with the name of the network that tokenized the contents. For instance, this could be a parameter "tokenized-by: example.com" added to the Via header. Obviously this parameter is not part of the tokenization procedure nor the final tokenized string.
- When an ingress SIP server receives a message, it analyzes the contents of the message. If it finds a "tokenized-by" parameter with the same network name (example.com), then it reverses the tokenization procedure, and applies normal procedures to the message (forwards to the ingress network without tokenized contents). 

For instance, an egress SIP server will tokenize the contents of the Via header and will replace:
Via: SIP/2.0/UDP proxy1.example.com, SIP/2.0/UDP as2.example.com, SIP/2.0/UDP egress.example.com

with:
Via: SIP/2.0/UDP token_for_proxy1_and_as2; tokenized-by=example.com

With these assumptions, any ingress SIP server is able to detect and reverse the tokenization process done by any egress SIP server in the same network. Therefore, in the event that a loop occurs, and the message is traversing twice a SIP proxy or application server, as the contents of Via and other headers are sent in the clear inside the network, the loop can be detected.

I understand this is a very high level solution. If people are happy or if I get enough comments, I can send further details on the proposed solution.

Of course, I would like to receive comments on this proposal.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Michael Hammer <[email-masked]>
Date: Thu, 20 Dec 2001 14:07:40 -0500

Miguel,

Could this be simplified further to say that the hiding proxy converts:

Via: SIP/2.0/UDP proxy1.example.com,
      SIP/2.0/UDP as2.example.com,
      SIP/2.0/UDP egress.example.com

to:

Via: SIP/2.0/UDP token_for_proxy1_and_as2.example.com

Wouldn't the implementation at the domain example.com know how to interpret 
the token and perform the corresponding expansion?  Does that require any 
new protocol elements?  (I would think not.)  Seems like all the 
information is local.

Mike

At 02:37 PM 12/20/2001 +0200, Miguel A. Garcia wrote:
>Hi:
>
>I would like to start a discussion on the hiding requirements (requirement 
>6.12) listed in draft-garcia-sipping-3gpp-reqs-02.txt
>
>The requirement reads: A network operator need not be required to reveal 
>the internal network structure to another network (in Via, Route, or other 
>headers) that may contain indication of the number of SIP proxies, domain 
>name of the SIP proxies, capabilities of the SIP proxies or capacity of 
>the network. Association of the node names of the same type of entity and 
>their capabilities and the number of nodes may be kept private within an 
>operator's network. However disclosure of the internal architecture must 
>not be prevented on a per agreement basis.
>
>Basically, the requirement is about not leaking information that may give 
>business intelligence to competitors, based on the number and name of 
>proxies, application servers, etc.
>
>In order to support this requirement, 3GPP has the concept of a "hiding 
>proxy". We can see this element as a SIP proxy located at the edge of the 
>network. This is the ingress point of signaling to a network (e.g., result 
>of a DNS SRV query). It may be also the egress point (kind of outbound proxy).
>
>The hiding proxy may tokenize the contents of a few headers (Via, Route, 
>Record-Route, etc), so that the contents are not readable to SIP proxies 
>outside the network.
>
>Although in draft-garcia-sipping-3gpp-reqs-02.txt we say that "We believe 
>that the requirements in this section are met by the current SIP protocol 
>[3]", I must say that this sentence will go away in the next version of 
>the draft. I think we need to do something else to support this requirement.
>
>The requirements is difficult to fulfill if we don't want to loose another 
>capability of SIP: the ability of detecting spirals and loops. Loops are 
>of particular interest, as it carries an error condition or configuration 
>error somewhere in the network.
>
>Having said that, I would like to discuss a possible solution to fulfill 
>the hiding requirement without loosing the loop/spiral detection capability.
>
>- When a message reaches the egress SIP server, it tokenizes those headers 
>that are needed. The result is a tokenized string that reflects a list of 
>contiguous SIP proxies or AS within the same network (think of a Via 
>header with a list of proxies).
>- The egress SIP server also adds an indication with the name of the 
>network that tokenized the contents. For instance, this could be a 
>parameter "tokenized-by: example.com" added to the Via header. Obviously 
>this parameter is not part of the tokenization procedure nor the final 
>tokenized string.
>- When an ingress SIP server receives a message, it analyzes the contents 
>of the message. If it finds a "tokenized-by" parameter with the same 
>network name (example.com), then it reverses the tokenization procedure, 
>and applies normal procedures to the message (forwards to the ingress 
>network without tokenized contents).
>
>With these assumptions, any ingress SIP server is able to detect and 
>reverse the tokenization process done by any egress SIP server in the same 
>network. Therefore, in the event that a loop occurs, and the message is 
>traversing twice a SIP proxy or application server, as the contents of Via 
>and other headers are sent in the clear inside the network, the loop can 
>be detected.
>
>I understand this is a very high level solution. If people are happy or if 
>I get enough comments, I can send further details on the proposed solution.
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 21 Dec 2001 09:39:32 +0200

> Via: SIP/2.0/UDP token_for_proxy1_and_as2.example.com

If we assume that the Via header for the egress.example.com remains as the top most Via header, that will work, I mean, there is not need for the "tokenized-by" parameter. It will require that the ingress proxy checks all the Via headers searching for his own domain, and trying to distinguis whether that Via header is another egress proxy or a tokenized one. I think it is easier for the ingress proxy to search for the tokenized-by parameter.

Further more, it gets more complicated when we apply the tokenization to other headers than Via (e.g., Route, Record-Route). In that case the ingress proxy would have a hard time to distinguish whether the contents are tokenized or not. Once more, the tokenized-by parameter helps on this task.

/Miguel

---

From: Michael Hammer <[email-masked]>
Date: Fri, 21 Dec 2001 10:36:44 -0500

Miguel,

If you need an explicit indication, another option might be to structure it as:

Via: SIP/2.0/UDP token_for_proxy1_and_as2.tokenized-by.example.com

Would that address the need to distinguish which names within example.com 
are tokenized?

Mike

At 09:39 AM 12/21/2001 +0200, Miguel A. Garcia wrote:
>If we assume that the Via header for the egress.example.com remains as the 
>top most Via header, that will work, I mean, there is not need for the 
>"tokenized-by" parameter. It will require that the ingress proxy checks 
>all the Via headers searching for his own domain, and trying to distinguis 
>whether that Via header is another egress proxy or a tokenized one. I 
>think it is easier for the ingress proxy to search for the tokenized-by 
>parameter.
>
>Further more, it gets more complicated when we apply the tokenization to 
>other headers than Via (e.g., Route, Record-Route). In that case the 
>ingress proxy would have a hard time to distinguish whether the contents 
>are tokenized or not. Once more, the tokenized-by parameter helps on this task.
>
>/Miguel
>
> >

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sat, 22 Dec 2001 17:50:12 +0200

Hi Michael:

Umm, this sounds good, and seems to be completely backward compatible. I like it. Thanks for the idea.

/Miguel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 22:49:35 -0500

There is an underlying assumption that an egress proxy only mucks with 
the via headers for the proxies in its own domain. Thats likely to be a 
nontrivial piece of configuration to accomplish. Its much simpler to 
simply encrypt/strip/tokenize everything up to the point of egress.

That said, I disagree in any case on the need to standardize anything. 
We removed via hiding from the spec, and replaced it with nothing, since 
we felt it could be done as a local implementation choice. The issue 
with loop detection that you raise is a good one, but there is a far, 
far easier solution, which is to simply use Max-Forwards. That is, any 
proxy that strips/tokenizes/encrypts the vias has to insert Max-Forwards 
with some reasonably sane value (10 should do). Loop detection is a 
fairly complex process, and given the frequency of occurrence of loops 
in a real network (nearly nil), a hop count can handle the corner case 
with far less complexity. Plus, it will make the approach for the 
hiding/stripping an implementation choice as I believe it should be.

-Jonathan R.

Miguel A. Garcia wrote:

>>If you need an explicit indication, another option might be to
>>
> structure it as:
> 
>>Would that address the need to distinguish which names within
>>
> example.com
> 
>>are tokenized?
>>
>>Mike
>>
>>>>Could this be simplified further to say that the hiding proxy
>>>>
> converts:
> 
>>>If we assume that the Via header for the egress.example.com remains
>>>
> as the
> 
>>>top most Via header, that will work, I mean, there is not need for
>>>
> the
> 
>>>"tokenized-by" parameter. It will require that the ingress proxy
>>>
> checks
> 
>>>all the Via headers searching for his own domain, and trying to
>>>
> distinguis
> 
>>>think it is easier for the ingress proxy to search for the
>>>
> tokenized-by
> 
>>>parameter.
>>>
>>>Further more, it gets more complicated when we apply the tokenization
>>>
> to
> 
>>>ingress proxy would have a hard time to distinguish whether the
>>>
> contents
> 
>>>are tokenized or not. Once more, the tokenized-by parameter helps on
>>>
> this task.
> 
>>>/Miguel
>>>
>>>
>>>>Wouldn't the implementation at the domain example.com know how to
>>>>
> interpret
> 
>>>>the token and perform the corresponding expansion?  Does that
>>>>
> require any
> 
>>>>>I would like to start a discussion on the hiding requirements
>>>>>
> (requirement
> 
>>>>>The requirement reads: A network operator need not be required to
>>>>>
> reveal
> 
>>>>>the internal network structure to another network (in Via, Route,
>>>>>
> or other
> 
>>>>>headers) that may contain indication of the number of SIP
>>>>>
> proxies, domain
> 
>>>>>name of the SIP proxies, capabilities of the SIP proxies or
>>>>>
> capacity of
> 
>>>>>the network. Association of the node names of the same type of
>>>>>
> entity and
> 
>>>>>their capabilities and the number of nodes may be kept private
>>>>>
> within an
> 
>>>>>operator's network. However disclosure of the internal
>>>>>
> architecture must
> 
>>>>>Basically, the requirement is about not leaking information that
>>>>>
> may give
> 
>>>>>business intelligence to competitors, based on the number and
>>>>>
> name of
> 
>>>>>In order to support this requirement, 3GPP has the concept of a
>>>>>
> "hiding
> 
>>>>>proxy". We can see this element as a SIP proxy located at the
>>>>>
> edge of the
> 
>>>>>network. This is the ingress point of signaling to a network
>>>>>
> (e.g., result
> 
>>>>>of a DNS SRV query). It may be also the egress point (kind of
>>>>>
> outbound
> 
>>>proxy).
>>>
>>>>>The hiding proxy may tokenize the contents of a few headers (Via,
>>>>>
> Route,
> 
>>>>>Record-Route, etc), so that the contents are not readable to SIP
>>>>>
> proxies
> 
>>>>>outside the network.
>>>>>
>>>>>Although in draft-garcia-sipping-3gpp-reqs-02.txt we say that "We
>>>>>
> believe
> 
>>>>>that the requirements in this section are met by the current SIP
>>>>>
> protocol
> 
>>>>>[3]", I must say that this sentence will go away in the next
>>>>>
> version of
> 
>>>>>the draft. I think we need to do something else to support this
>>>>>
>>>requirement.
>>>
>>>>>The requirements is difficult to fulfill if we don't want to
>>>>>
> loose another
> 
>>>>>capability of SIP: the ability of detecting spirals and loops.
>>>>>
> Loops are
> 
>>>>>of particular interest, as it carries an error condition or
>>>>>
> configuration
> 
>>>>>Having said that, I would like to discuss a possible solution to
>>>>>
> fulfill
> 
>>>>>the hiding requirement without loosing the loop/spiral detection
>>>>>
>>>capability.
>>>
>>>>>- All ingress and egress SIP servers in the network share the
>>>>>
> same
> 
>>>>>"tokenization/detokenization" algorithm.
>>>>>- When a message reaches the egress SIP server, it tokenizes
>>>>>
> those headers
> 
>>>>>that are needed. The result is a tokenized string that reflects a
>>>>>
> list of
> 
>>>>>contiguous SIP proxies or AS within the same network (think of a
>>>>>
> Via
> 
>>>>>- The egress SIP server also adds an indication with the name of
>>>>>
> the
> 
>>>>>network that tokenized the contents. For instance, this could be
>>>>>
> a
> 
>>>>>parameter "tokenized-by: example.com" added to the Via header.
>>>>>
> Obviously
> 
>>>>>this parameter is not part of the tokenization procedure nor the
>>>>>
> final
> 
>>>>>tokenized string.
>>>>>- When an ingress SIP server receives a message, it analyzes the
>>>>>
> contents
> 
>>>>>of the message. If it finds a "tokenized-by" parameter with the
>>>>>
> same
> 
>>>>>network name (example.com), then it reverses the tokenization
>>>>>
> procedure,
> 
>>>>>and applies normal procedures to the message (forwards to the
>>>>>
> ingress
> 
>>>>>For instance, an egress SIP server will tokenize the contents of
>>>>>
> the Via
> 
>>>>>header and will replace:
>>>>>Via: SIP/2.0/UDP token_for_proxy1_and_as2;
>>>>>
> tokenized-by=example.com
> 
>>>>>With these assumptions, any ingress SIP server is able to detect
>>>>>
> and
> 
>>>>>reverse the tokenization process done by any egress SIP server in
>>>>>
> the same
> 
>>>>>network. Therefore, in the event that a loop occurs, and the
>>>>>
> message is
> 
>>>>>traversing twice a SIP proxy or application server, as the
>>>>>
> contents of Via
> 
>>>>>and other headers are sent in the clear inside the network, the
>>>>>
> loop can
> 
>>>>>be detected.
>>>>>
>>>>>I understand this is a very high level solution. If people are
>>>>>
> happy or if
> 
>>>>>I get enough comments, I can send further details on the proposed
>>>>>
>>>solution.
>>>
>>>>>Sipping mailing list
> http://www1.ietf.org/mailman/listinfo/sipping
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 28 Dec 2001 10:18:42 +0200

> simply encrypt/strip/tokenize everything up to the point of egress. 

Although it is simpler to tokenized everything up to the point of egress,
we loose the main property of the Via header, the capability of distinguish
between spirals and loops. If we want to preserve this capability, an egress
point that tokenizes only those headers inserted by other proxy in his domain
will do its job. This can be easily done if the egress point has knowledge 
of the domain name he is tokenizing or the network part of the IP address (in 
case of IP addresses).

> That said, I disagree in any case on the need to standardize anything.

I agree there is no need to standardize something in SIP. However, in 3GPP
we are defining a SIP profile, and that profile may include a mechanism to
tokenize headers in 3GPP networks. So, hopefully there is nothing to standardize
in SIP, but some recommendations for 3GPP networks.

> hiding/stripping an implementation choice as I believe it should be.

As Bill Marshall has pointed out, the Max-Forwards, although it works nicely
for the purpose of loop detection, has the problem that a proxy cannot insert
it if the Max-Forwards wasn't present in the request (table 2 categorizes the
Max-Forwards with "rm" in the proxy column). Is there any rational behind this
restriction or is it something that can be fixed in bis-06?

Thanks a lot,

   Miguel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Dec 2001 10:41:13 -0500

>>proxy that strips/tokenizes/encrypts the vias has to insert
>>
> Max-Forwards
> 

I will fix it in bis-06. Doing this is much cheaper and simpler than 
specifying via hiding mechanisms.

-Jonathan R.