Subject: Re: [Gen-art] Gen-ART review of draft-ietf-sipping-config-framework-16

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 4 Jan 2010 17:34:25 -0500

Sumanth Channabasappa wrote:
Hi, Sumanth,

> Peter,
> 
> Regarding the local network profile, the intent was to provide a
> mechanism for local networks (which can be a end-user's local network
> or a Service Provider's network) to provide any information that can
> help the end-device operate efficiently. While bandwidth is one
> example, others include outbound proxy to reach the external world.  

I thought the outbound proxy was already configured with a DHCP option.
(not that you should need one anyway).  I should be able to reach the
external world over raw IP, without having to implement particular
application protocols.

> Can this be used abusively, e.g., to exercise control? Potentially.
> However, the end-device may be configured to not request or use such
> information when it does not feel the need.  

If we can't justify it maybe we should remove the option.

-Pete

> - S
> 
> 
> On 12/29/09 2:39 PM, "McCann Peter-A001034" <[email-masked]>
> wrote:
> 
>> Hi, Gonzalo,
>> 
>> I agree completely that local networks shouldn't modify the
>> end-to-end SIP messages.  However, I would go even further and say
>> that they shouldn't be imposing these "policies" against certain
>> codecs in the first place. One of the fruits of the end-to-end
>> principle of system design is that end users can deploy whatever
>> applications they want without asking permission from the network. 
>> Do we really want to give intervening networks the tools to control
>> these applications? 
>> 
>> -Pete
>> 
>> 
>> Gonzalo Camarillo wrote:
>>> Hi Peter,
>>> 
>>> local networks enforce these types of policies anyway. Currently,
>>> they do it using SBCs (Session Border Controllers) that rewrite the
>>> SIP signalling and open and close firewalls. This mechanism allows
>>> the local network to inform the UA about the policy so that the UA
>>> can comply with it. In this way, the local network does not need to
>>> break the SIP signalling and modify the end-to-end messages between
>>> the endusers (these modifications cause a lot of problems in SIP
>>> networks). Therefore, what this mechanism does it preserving the
>>> end-to-end communication between the endpoints.
>>> 
>>> Cheers,
>>> 
>>> Gonzalo
>>> 
>>> McCann Peter-A001034 wrote:
>>>> I have been selected as the General Area Review Team (Gen-ART)
>>>> reviewer for this draft (for background on Gen-ART, please see
>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html
>>>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).
>>>> 
>>>> Please resolve these comments along with any other Last Call
>>>> comments you may receive. 
>>>> 
>>>> Document: draft-ietf-sipping-config-framework-16
>>>> Reviewer: Pete McCann
>>>> Review Date: 2009-12-22
>>>> IETF LC End Date: 2009-12-24
>>>> IESG Telechat date: unknown
>>>> 
>>>> Summary: One big issue to discuss
>>>> 
>>>> Major issues:
>>>> 
>>>> I don't understand why the local network needs to be involved in
>>>> SIP provisioning.  The end-to-end principle should dictate that
>>>> SIP is an application that runs transparently over intervening
>>>> networks. 
>>>> 
>>>> From Section 3.2:
>>>>    In such cases, local
>>>>    network providers may wish to provide local network information
>>>>    such as bandwidth constraints to the devices.
>>>> Why should the bandwidth constraints applicable to SIP be any
>>>> different from the bandwidth constraints applied to any other
>>>> application? 
>>>> 
>>>> I suggest dropping the local-network profile type.
>>>> 
>>>> Minor issues:
>>>> 
>>>> Figure 5 is confusing: it shows user A obtaining service before
>>>> user A's profile is downloaded.  Similar for user B.  Shouldn't the
>>>> profile be downloaded to the kiosk before service is provided?
>>>> 
>>>> Section 5.2.1:
>>>>    Additionally, the device MUST authenticate the PDS
>>>>    to ensure that it is obtaining sensitive profile data from a
>>>>    valid PDS, except in the bootstrapping scenario.
>>>> Why not in the bootstrapping scenario?  That seems to be the most
>>>> critical operation. 
>>>> 
>>>> 
>>>> Nits/editorial comments:
>>>> 
>>>> Section 5.1.4.2:
>>>>    it MUST be
>>>>    use
>>>> SHOULD BE:
>>>>    it MUST use
>>>> 
>>>> Section 9:
>>>>    The framework specified in this documents SHOULD BE:
>>>>    The framework specified in this document
>>>> 
>>>> Section 9.1:
>>>>    in the absence TLS
>>>> SHOULD BE:
>>>>    in the absence of TLS
>>>> 
>>>> _______________________________________________
>>>> Gen-art mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 11 Jan 2010 13:06:07 +0200

Hi Peter,

this is something the WG discussed at great length and the conclusion 
was to have local policies. Note that local policies are also used by 
the policy framework:

http://www.ietf.org/id/draft-ietf-sip-session-policy-framework-06.txt

In the WG there were people that, like you, thought SIP entities should 
not be concerned with media level stuff such as bandwidth, codecs, etc. 
However, the fact is that in real-life deployments SIP operators 
implement these policies, whether we like it or not, using SBCs. Having 
local policies provides them with a way to implement these policies 
without violating the end-to-end principle in SIP. That is, they can 
implement these policies without having an SBC modify messages between 
the user agents.

The bottom line is that your concerns were shared by some people in the 
WG and, thus, were discussed at length when this spec was written. 
Therefore, at this point, I do not think we should revisit that 
discussion since the arguments for and against are the same as they were 
at the time of writing the spec.

Cheers,

Gonzalo

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 11 Jan 2010 13:29:06 -0500

Hi, Gonzalo,

I understand that the spec is the result of long discussion in
the WG to which I am coming late.  My apologies.  One of the
purposes of the Gen-ART review is to bring up questions that
relate to whether the document is a good idea for the Internet
as a whole.

I share your concerns about SBCs modifying SIP messages.  That
shouldn't happen.  If an access network does this they are not
providing true Internet service.  However, I think it is the 
actual imposition of the kinds of policies discussed in the
draft, rather than the actual mechanism, that is the violation
of the end-to-end principle that will lead to more fragile,
less flexible architectures.  I.e., adding explicit signaling
to a middlebox so it doesn't have to modify the SIP messages
does little to address the larger architectural question.

While I understand that some access networks might want to limit
the bandwidth consumed by a user under congestion conditions, it
seems to me that more generic mechanisms, that apply to all
applications instead of just SIP applications, would be more
appropriate.
I don't understand at all why an access network would care about
the codec used by a particular application.  That seems strictly
a matter for end-to-end negotiation between the participants in a
call.

I'll let Russ decide whether he wants to bring the issues I've raised
to the attention of the IESG.

-Pete

Gonzalo Camarillo wrote:
> In the WG there were people that, like you, thought SIP entities
> should not be concerned with media level stuff such as bandwidth,
> codecs, etc.  
> implement these policies, whether we like it or not, using SBCs.
> Having local policies provides them with a way to implement these
> policies without violating the end-to-end principle in SIP. That is,
> they can implement these policies without having an SBC modify
> messages between the user agents.     
> 
> The bottom line is that your concerns were shared by some people in
> the WG and, thus, were discussed at length when this spec was
> written.  
> discussion since the arguments for and against are the same as they
> were at the time of writing the spec.  
> 
> Cheers,
> 
> Gonzalo
> 
> 
> 
>>> mechanism for local networks (which can be a end-user's local
>>> network or a Service Provider's network) to provide any information
>>> that can help the end-device operate efficiently. While bandwidth
>>> is one example, others include outbound proxy to reach the external
>>> world. 
>> 
>> I thought the outbound proxy was already configured with a DHCP
>> option. (not that you should need one anyway).  I should be able to
>> reach the external world over raw IP, without having to implement
>> particular application protocols. 
>> 
>>>> Do we really want to give intervening networks the tools to
>>>> control these applications? 
>>>> 
>>>> -Pete
>>>> 
>>>> 
>>>> Gonzalo Camarillo wrote:
>>>>> Hi Peter,
>>>>> 
>>>>> they do it using SBCs (Session Border Controllers) that rewrite
>>>>> the SIP signalling and open and close firewalls. This mechanism
>>>>> allows the local network to inform the UA about the policy so
>>>>> that the UA can comply with it. In this way, the local network
>>>>> does not need to break the SIP signalling and modify the
>>>>> end-to-end messages between the endusers (these modifications
>>>>> cause a lot of problems in SIP networks). Therefore, what this
>>>>> mechanism does it preserving the end-to-end communication between
>>>>> the endpoints. 
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Gonzalo
>>>>> 
>>>>>>    network providers may wish to provide local network
>>>>>>    information such as bandwidth constraints to the devices.
>>>>>> user A's profile is downloaded.  Similar for user B.  Shouldn't
>>>>>> the profile be downloaded to the kiosk before service is
>>>>>> provided? 
>>>>>> 
>>>>>> Section 5.2.1:
>>>>>> Why not in the bootstrapping scenario?  That seems to be the
>>>>>> most critical operation. 
>>>>>> 
>>>>>> 
>>>>>> Nits/editorial comments:
>>>>>> 
>>>>>> Section 5.1.4.2:
>>>>>>    it MUST be
>>>>>>    use
>>>>>> SHOULD BE:
>>>>>>    it MUST use
>>>>>> 
>>>>>> Section 9:

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 11 Jan 2010 21:30:43 +0200

Hi Peter,

> does little to address the larger architectural question.

the point I am trying to make is that it does not matter whether or not 
you or I like the fact that operators enforce local policies. We don't 
like it, but they do it and they will continue doing it. That is a fact. 
That is the reality of VoIP deployments.

Now, architecturally, it is much better to have explicit signalling 
between the middlebox and the UA than just having the middlebox change 
things without informing anyone (like NATs do).

Your proposal of not providing the explicit signalling mechanism will 
not keep operators from enforcing local policies but will keep them from 
signalling them explicitly. The consequence will be that you will have a 
NAT-like device modifying messages without informing anyone.

Therefore, it seems that by not standardizing the mechanism we would be 
worse off.

> a matter for end-to-end negotiation between the participants in a

Some networks can make use of codec-specific optimizations or restrict 
codec usage based on bandwidth consumption. When you are managing a busy 
cellular network, you do not want terminals using G.711 on it... and you 
need a mechanism to tell them that the maximum bandwidth they can use is 
well below 64 kpbs. So, they'd better use AMR.

> to the attention of the IESG.

Sure, that sounds sensible.

Thanks,

Gonzalo