Subject: Re: [Sipping] 3GPP Hiding requirements

From: William Marshall <[email-masked]>
Date: Thu, 27 Dec 2001 07:57:16 -0500 (EST)

Jonathan Rosenberg wrote, in part:
> 					...	That is, any 
> proxy that strips/tokenizes/encrypts the vias has to insert Max-Forwards 
> with some reasonably sane value (10 should do). ...

This solution sounds good, and also covers the tricky case of multiple
entities doing hiding and passing the request to each other.

Will the next version of bis allow a proxy to insert a Max-Forwards header?

Bill Marshall
[email-masked]

-----original message-----
Date: Wed, 26 Dec 2001 22:49:35 -0500
From: Jonathan Rosenberg <[email-masked]>
To: "Miguel A. Garcia" <[email-masked]>
Cc: Michael Hammer <[email-masked]>, [email-masked]
Subject: Re: [Sipping] 3GPP Hiding requirements

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:

> Hi Michael:
> 
> Umm, this sounds good, and seems to be completely backward compatible. I
> like it. Thanks for the idea.
> 
> /Miguel
> 
> Michael Hammer wrote:
> 
>>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:
>>
>>>Michael Hammer wrote:
>>>
>>>>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
>>>>
>>>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
>>>
>>>
>>>>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.
>>>
>>>>>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
>>>>>
>>>--
>>>Miguel-Angel Garcia                     Oy LM Ericsson AB
>>>                                        Jorvas, Finland
>>>mailto:[email-masked]     Phone:  +358 9 299 3553
>>>mailto:[email-masked]        Mobile: +358 40 5140002
>>>
> 

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

_______________________________________________
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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 12:45:39 -0500

William Marshall wrote:

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

I think its reasonable. I will add that.

-Jonathan R.