Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

From: "Even, Roni" <[email-masked]>
Date: Tue, 6 Nov 2007 18:09:00 +0200

Hi,

In general to me it looks OK.

Some issues with the examples

1. In section 7.1 the subscribe has a URN for the From: field but
section 5.1.4.2 says for device profile "The device MUST set the "From"
field to a value of anonymous@<device provider's domain>"

2. The To tag in the notify for the above subscription should be 1234

3. In section 7.2 in the second notify you change the tags , but I think
that the notify is for the same subscription as the first notify so they
should have the same tags.

Roni Even

> -----Original Message-----

> From: Mary Barnes [mailto:[email-masked]]

> Sent: Friday, October 26, 2007 6:08 PM

> To: [email-masked]

> Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

> Folks,

> This email is to announce a two week post-WGLC review of the changes

> made to this document. The diff is available at:

http://tools.ietf.org/wg/sipping/draft-ietf-sipping-config-framework/dra

> ft-ietf-sipping-config-framework-13-from-12.diff.html

> Please review the changes and post any comments on those changes to
the

> list on or before November 9th, 2007.   If you think the doc is
"Ready",

> please post a comment to the list as well.

> Regards,

> Mary.

> SIPPING WG co-chair

> -----Original Message-----

> From: Sumanth Channabasappa [mailto:[email-masked]]

> Sent: Friday, October 26, 2007 10:59 AM

> To: [email-masked]

> Subject: [Sipping] Summary: draft-ietf-sipping-config-framework-13

> Folks,

> A new version (-13) of the SIP Configuration Framework is now
available.

> http://tools.ietf.org/html/draft-ietf-sipping-config-framework-13.txt

> This includes comments and suggestions from various folks (John
Elwell,

> Shida Schubert, Dave Robbins, Roni Even, Markus Isomaki, and Peter

> Blatherwick come to mind - thanks to everyone else as well). As a
note,

> I did not include changes that were already agreed upon in previous
IETF

> meetings (esp. layout). Other changes are a result of discussions

> between Josh, Dan and myself.

> To summarize the changes:

> (Mostly) Technical Changes:

> - Added clarification on the use of Outbound based on discussions with

> Rohan, Cullen and Peter. This was raised by Markus at the last IETF

> since it was unclear as to how Outbound is used for the initial SIP

> SUBSCRIBE (prior to registration).

> - Removed the term 'device AoR' within the device profile. (We still

> allow for configured AoRs to override discovered AoRs.)

> - Clarified a few areas in the Security section

> - Added clarification regarding user profile retrieval

> Editorial Changes:

> - Removed Section on "Executive Summary", minimized repetition in the

> initial sections (e.g., Overview)

> - Added clarification of new terms, such as profile data, early on

> - Affected various editorial changes

> - S

> _______________________________________________

> Sipping mailing list  https://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  https://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  https://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: "Sumanth Channabasappa" <[email-masked]>
Date: Thu, 8 Nov 2007 15:24:15 -0700

John,

As always, your comments and suggestions are appreciated. I am glad that
the edits align better with the expectations of the WG (based on
comments from you and the others - thanks). Additionally, your comments
related to the security sections definitely help.

I have enclosed some responses. If there are comments to which I have
not responded, it either means that I concur and will make the necessary
edits, or they are repetitions of comments already addressed.

1. "PDSs and devices will implement all the three profile types.  Unless
configured otherwise, a device will try to obtain all the three profile
types"

Shouldn't there be a means by which the first profile downloaded can
indicate if there is no need to fetch additional profiles? This would
avoid pre-configuration.
[S] Yes. And while the idea of 'unless configured otherwise' allows for
pre-configuration (or manual configuration), the idea was that this
could be relied via a profile that provides configuration data. I can
add some text to indicate this explicitly.

2. "There are no proxies in the network"
This assumption for the Simple Deployment Scenario seems to suggest a
P2P network, which should be outside the scope of this document (a
matter for the P2PSIP group). Does it mean that UAs can contact the PDS
without going through a proxy? If so, say so. However, I am not sure how
typical this case would be. Once configured with an outbound proxy
(which is the norm), future SIP requests, including any SUBSCRIBE or
re-SUBSCRIBE requests to this package, will go through the outbound
proxy according to normal RFC 3261 rules. We shouldn't specify anything
in contradication.
[S] This is a use case that illustrates how the device can connect
directly to a PDS without going through a proxy. I think this is valid
in some cases. (The addition of a proxy does not complicate the use case
in any way.)

3. 
   (B)  The device performs Profile Enrollment for the device profile ;
        the device profile data is contained in the enrollment
        notification."
Why the device profile? Since the local-network profile is normally
gathered before the device profile, wouldn't the local network profile
be more suitable for this Simple Deployment Scenario?
[S] Per the assumptions listed earlier, the device is configured (either
pre-configuration or via a previous profile download) to only request
the 'device profile'. This is to illustrate a case where a provider
wants to support one profile that contains all the relevant data and has
no use for a local-network profile. 

7. "The device MUST set the Request URI to the user AoR".
I can't figure out how this will work if the SUBSCRIBE request gets
routed via a standard proxy. It seems it would get routed to any
registered contacts for that AoR. Of course, if the user profile PDS is
a registered contact, it will get sent there too. Without looking at the
Event header field, it is impossible for a proxy to determine that such
a SUBSCRIBE request requires special treatment.
[S] A standard proxy is going to send the request to an authoritative
proxy for the domain, which must decide as to where the SUBSCRIBE
request gets routed. At this point in time, it would have to look at the
Event Package parameters. This has not been changed for the last few
revisions of the I-D. 

8. "In the absence of a Server Identity authenticated TLS session with
   the next-hop SIP entity:
   o  the device MUST NOT respond to any authentication challenges"
The requirement to use TLS is only SHOULD, so if you don't use TLS, you
can never respond to an authentication challenge. This doesn't make
sense.
[S] The requirement is that TLS MUST be established when a SIPS URI is
used. The requirement also says that it SHOULD in all other cases, the
only exception being explicit configuration to not use TLS. 

The requirement to not respond to authentication challenges is to
protect the device from security threats in the absence of a
provider-authenticated, integrity protected, channel. In other words, an
Operator who plans to challenge the client should allow it to use TLS. 

9. "the device MUST ignore any notifications containing sensitive
      profile data"
How does the device know which data is sensitive? Is this something that
has to be defined with each profile? If so, we need some statement.
[S] We already have a requirement in Section 5.3.4 for a profile to
explicitly indicate the presence of sensitive profile data. 

10. "Once enrolled, the device obtains the initial notification.  This
is
   authenticated using two methods.  If this initial notification was
   transmitted on the mutually authenticated TLS session established for
   enrollment requests, then it is considered authenticated"
This only works if the TLS session is end-to-end, i.e., no proxy between
the UA and the PDS. If there is a proxy, it is only the proxy that is
authenticated, not the PDS.
[S] I agree that the component authenticated in your scenario is the
proxy. However, this proxy is expected to belong to the Operator
controlling the PDS, and you are authenticating the domain name (given
the DNS resolution using the domain name lead to the proxy in the first
place). Thus, an authenticated channel with the next-hop (PDS or proxy)
is presented as equivalent to authentication of the provider. In the
case that this is a proxy, I agree that it does not authenticate the
PDS. Perhaps we should clarify that?

11. "If the
   SIP Identity header is absent or the device cannot validate it"
If the profile needs to be downloaded in order to install the CA
certificate, the device will be unable to validate the server and we
have a deadlock situation.
[S] There are two cases here. The client may already contain a CA
certificate, in which case this works fine. Alternatively, in the case
when the device is being bootstrapped, the data may still contain the CA
Certificate, and it can use it to validate the SIP Identity header
before committing the profile data (assuming it belongs to the domain
name that it used to obtain the profile data in the first place).
Perhaps we should clarify this better?

13. "If the SIP Identity
   header is present, and the device cannot validate it, then it MUST
   reject the profile data and retry enrollment"
This seems to contradict the previous sentence - two conficting actions
for the case where cannot validate.
[S] I actually think that they are redundant actions for the same
condition. The first one says 'reject sensitive profile data', the
second says 'reject profile data as well'. I can reword to clarify (the
intent was the same behavior in both cases).

14. "or those in deployments where communication with
   the PDS in the absence of a mutually authenticated TLS is
disallowed."
Which hop are we talking about - device-to-proxy, inter-proxy,
proxy-to-PDS? I guess there could be closed environments where it is
known that all hops use TLS, or SIPS could be used to ensure this is the
case. Seems to require more explanation.
[S] I agree. The intent here is that if a SIPS URI is always used,
resulting in security across all hops, then you are fine.

16. "If known by
   the PDS and the notification will result in data specific to the user
   AoR, the PDS MUST challenge the request using Digest authentication
   specified in [RFC3261]"
There needs to be some discussion about realm. Does the PDS necessarily
use the same realm that the device uses with its domain proxy/registrar?
[S] I am not sure if the realm, and hence the protection domain, needs
to be the same (tho' it can be). Do we necessarily need to specify this,
even if we are not proposing it one way or the other? (Perhaps I am
missing something?)

17. "If the device established TLS with the next-hop entity then any
such notifications SHOULD be sent over the same TLS session by the PDS."
We should not preclude multiple TLS sessions (in accordance with
SIP-outbound) and should not preclude a TLS session having been
re-established following loss of an earlier session.
Furthermore, sending over the same TLS session from PDS to proxy does
not guarantee it will be sent over the same TLS session from proxy to
UA. Therefore what do we achieve by recommending it be sent over the
same TLS session?
[S] I think we wanted to say that if a previously established TLS
session still existed, it should use the same channel. The idea being
the presence of an authenticated channel to send the NOTIFY. We did not
plan to preclude the presence of multiple TLS sessions. Perhaps we need
to clarify that.

18. "If no such TLS session exists, the
   device MUST NOT accept any sensitive profile data without verifying
   the presence of, and validating, a SIP Identity header."
The use of TLS is not necessarily a substitute for this, unless the TLS
session is end-to-end, not via a proxy.
[S] If the mutually-authenticated TLS is via a proxy that belongs to the
Provider, then the device is asked to trust the connection (not my first
choice). If we do not want to trust the proxy, we can use SIP Identity
for authentication, but not privacy. In other words, the PDS would need
to include the SIP Identity in all cases that it does not directly speak
to a device via mutually-authenticated TLS. I am OK with that (unsure
why we relaxed it). Do we have other options here?

23. "and add the "ob" parameter as specified
   in [I-D.ietf-sip-outbound] within the SIP SUBSCRIBE for profile
   enrollment."
In sip-outbound, I can only find reference to use of "ob" in REGISTER
requests. It appears to have no meaning in a SUBSCRIBE request.
[S] This was suggested by the Outbound authors (Rohan), with the
understanding that this will be extended in the next revision. 

- S

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Thu, 8 Nov 2007 15:25:54 -0700

Thanks, Roni.  Your observations are correct and will be included in a
revision.

- S

________________________________

From: Even, Roni [mailto:[email-masked]] 
Sent: Tuesday, November 06, 2007 9:09 AM
To: Mary Barnes; [email-masked]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Hi,

Roni Even

the

"Ready",

available.

Elwell,

note,

IETF

---

From: <[email-masked]>
Date: Fri, 9 Nov 2007 14:15:55 +0200

Hi,

Thanks for the updated draft, Sumanth. I think this is in principle on
the right track, but as you see below I still think we need to see the
new version of sip-outbound before moving forward. This is because I'd
like to have the config-framwork to have a solid NAT traversal solution
from the start, so that we don't end up in similar difficulties as with
SIP and NATs in genearal in the past. I think  the updates on
config-framework were done as agreed, so now the ball is on
sip-outbound's part of the court.

I did a review focusing on this part:
>- Added clarification on the use of Outbound based on 
>discussions with Rohan, Cullen and Peter. This was raised by 
>Markus at the last IETF since it was unclear as to how 
>Outbound is used for the initial SIP SUBSCRIBE (prior to registration).

1.) The draft makes a few normative references to sip-outbound, such as
this in Section 5.1.4.1:
   "The device MUST include the +sip.instance parameter within the
   'Contact' header, as specified in [I-D.ietf-sip-outbound]."
This means that sip-outbound should also be changed from informative to
normative reference in the References section.

2.) Usage of Outbound is detailed in Section 5.4. I think this is
getting to the right direction, but a couple of major issues still
remain. The Section as a whole says:
   "PDSs that support devices behind NATs, and devices that can be
behind
   NATs can use procedures specified in [I-D.ietf-sip-outbound].  The
   Outbound proxies can be configured or discovered.  Clients that
   support such behavior MUST include the 'outbound' option-tag in a
   Supported header field value, and add the "ob" parameter as specified
   in [I-D.ietf-sip-outbound] within the SIP SUBSCRIBE for profile
   enrollment."
- Current sip-outbound draft still only covers the case where REGISTER
transaction is performed before anything else is done. In
config-framework in some scenarios it would be useful (or even
necessary) to send SUBSCRIBE to the PDS before registering. From
config-framework point of view the current text on the 'outbound' option
tag and 'ob' poarameter maybe enough (this was the high-level conclusion
in the thread with sip-outbound editors), but before concluding that we
will have to see a version of sip-outbound which actually describes how
sip-outbound handles this case in general. 
- It is said that the "Outbound proxies can be configured or
discovered". This information is needed before sending SUBSCRIBE in case
there's a NAT between UA and PDS. I believe this is extremely common in
many consumer SIP/VoIP scenarios. sip-outbound does not define how the
outbound proxies are discovered, instead it makes a vague reference on
config-framework. So, in practice there is no discovery mechanism for an
UA when it is first taken into use with an account from a SIP service
provider. This leaves manual configuration as the only option. So,
instead of the user having to type in their AoR and digest password,
they also have to type in the Outbound proxy URI. This may not seem like
a big deal, but since we are developing an automated config solution for
SIP UAs, I think it should be one of the basic requirements that the
user MUST NOT need to manually configure such parameters as proxy
addresses. 

As a summary I would still like to understand two things in the overall
UA config solution:
a) how does sip-outbound deal with SUBSCRIBE before REGISTER.
b) how does UA discover its outbound proxy, so that the user does not
need to type it in.

I don't care in which document these issues are dealt with. 'a)' seems
to clearly belong to sip-outbound, 'b)' could be in sip-outbound,
config-framework or in some new doc. So, perhaps config-framework will
not need to be changed, but I think SIP WG needs to resolve these issues
before passing config-framework to IESG. 

Regards,
	Markus 

>From: ext Mary Barnes [mailto:[email-masked]] 
>Sent: 26 October, 2007 19:08
>To: [email-masked]
>This email is to announce a two week post-WGLC review of the 
>changes made to this document. The diff is available at:
>Please review the changes and post any comments on those changes to the
>list on or before November 9th, 2007.   If you think the doc 
>is "Ready",
>This includes comments and suggestions from various folks 
>(John Elwell, Shida Schubert, Dave Robbins, Roni Even, Markus 
>Isomaki, and Peter Blatherwick come to mind - thanks to 
>everyone else as well). As a note, I did not include changes 
>that were already agreed upon in previous IETF meetings (esp. 
>layout). Other changes are a result of discussions between 
>Josh, Dan and myself.
>
>- Added clarification on the use of Outbound based on 
>discussions with Rohan, Cullen and Peter. This was raised by 
>Markus at the last IETF since it was unclear as to how 
>Outbound is used for the initial SIP SUBSCRIBE (prior to registration).
>- Removed the term 'device AoR' within the device profile. (We 
>still allow for configured AoRs to override discovered AoRs.)
>- Removed Section on "Executive Summary", minimized repetition 
>in the initial sections (e.g., Overview)
>[email-masked] for questions on current sip 
>[email-masked] for questions on current sip

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Fri, 9 Nov 2007 07:37:20 -0500

I see the corrections from Roni etc and that is great.  But hanging this
on to the progress of outbound is like saying we wont do anything to sip
until the essential corrections to sip or done and finished and
delivered as an RFC.  They should be kept independent of each other
IMHO.  If something is in the scope of outbound... It is not in the
scope of config-framework and we can state it as such.  But I most
definitely don't agree with holding this up until something else is
done.  BTW, TISPAN etc wil move ahead and mandate their own version of
config-framework independent of and with no reference to ietf if we
delay this until the planets are in alignemnt again.  ATIS is also
marching in that direction.  We have been trying to get tispan and atis
to wait until there is a basic framework from IETF... So for heavens
sake don't let them take off in a random direction without any guidance
from the IETF

Sam

PS: Let us also not forget that it has been what 3 years since this
started....

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, November 09, 2007 7:16 AM
To: [email-masked]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Hi,

Regards,
	Markus 

>This includes comments and suggestions from various folks (John Elwell,

>Blatherwick come to mind - thanks to everyone else as well). As a note,

>IETF meetings (esp.
>layout). Other changes are a result of discussions between Josh, Dan 
>and myself.
>

---

From: <[email-masked]>
Date: Fri, 9 Nov 2007 15:13:32 +0200

Hi,

Ganesan Sam-W00184 [mailto:[email-masked]] wrote:
>
>I see the corrections from Roni etc and that is great.  But 
>hanging this on to the progress of outbound is like saying we 
>wont do anything to sip until the essential corrections to sip 
>or done and finished and delivered as an RFC.  

Otherwise I agree with you, but currently config-framework relies on
functionality in sip-outbound that is not (yet) described in
sip-outbound. Building on work-in-progress is usually fine if things are
modular and the interface is clear, but building on non-existing
functionality is more dangerous, if you believe such functionality is
essential. In practice we should see the next rev of sip-outbound in a
matter of couple of weeks, and hopefully this clears the issue.

>They should be 
>kept independent of each other IMHO.  If something is in the 
>scope of outbound... It is not in the scope of 
>config-framework and we can state it as such.  But I most 
>definitely don't agree with holding this up until something 
>else is done.  BTW, TISPAN etc wil move ahead and mandate 
>their own version of config-framework independent of and with 
>no reference to ietf if we delay this until the planets are in 
>alignemnt again.  ATIS is also marching in that direction.  We 
>have been trying to get tispan and atis to wait until there is 
>a basic framework from IETF... So for heavens sake don't let 
>them take off in a random direction without any guidance from the IETF
>

Politics between SDOs is important and I agree ATIS and TISPAN should
follow IETF, but I am worried about having an RFC that can be
implemented and deployed for UAs behind NATs. 

Perhaps we should just take a poll to see how many people/vendors who
will implement this without Outbound (no NAT traversal, or some
proprietary method to do it between UA and proxy for SUBSCRIBEs before
registration). If there are enough of those, it makes sense to go ahead.
If most people think Outbound is essential for this, faster timeline
might not be that useful.

>Sam
>
>PS: Let us also not forget that it has been what 3 years since 
>this started....
>

I thought it was 7... :-( I agree that it would matter if I was
requesting some new corner-case features, but NAT traversal seems to me
like a major point.

Markus

---

From: [email-masked]
Date: Fri, 9 Nov 2007 10:13:45 -0500

Hi,
I think we can generally agree that NAT traversal is not a corner case -- 
must be solved -- no "poll" really needed for that.  But I certainly agree 
with Sam and others here -- Config Framework needs to be progressed ASAP!! 
  It is waaaaaaay overdue.  Even aside from other SDOs moving ahead (which 
would just shoot everybody in the foot of course), real product vendors 
are also continuing to implement their own solutions, which can (and do) 
diverge from this, and become entrenched over time -- the problem only 
gets worse as even more time passes. 

I would counter-propose that we aggressively separate concerns, to allow 
Config Framework to move forward now.  In particular: 

o Outbound needs to describe usage during SUBSCRIBE (possibly other 
non-REGISTER cases as well).  Clearly out of scope for Config Framework. 

o Outbound or some other document should describe discovering the outbound 
proxy set.  It is a generic problem not specific to configuration, 
therefore should be out of scope for Config Framework.  Let's say that out 
loud in the document, and move on. 

o Markus' statement "... should be one of the basic requirements that the 
user MUST NOT need to manually configure such parameters as proxy 
addresses."  should also be declared out of scope for Config Framework 
itself.  It is really part of the point above (discovery of outbound proxy 
set).  And anyway, even if there is some still some manual configuration 
required in some scenarios, it becomes far simpler process with the aid of 
the Config Framework, so would be a major step forward. 

(Aside: On the 2nd point above, I also think outbound should not refer to 
config framework for this, but that's really a comment on that other 
document.) 

With the corrections Markus points to below (normative reference etc) and 
a few others we have seen, and with some cleanup to say what is out of 
scope (as above), plus waiting to see next rev of outbound with updates 
around the non-REGISTER usage (real soon now, right?!), can we agree to 
progress Config Framework?  (PLEASE ?!?!) 

-- Peter

<[email-masked]>
09.11.07 08:13
 
        To:     <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: [Sipping] Summary: 
draft-ietf-sipping-config-framework-13

Hi,

Markus

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 9 Nov 2007 07:24:58 -0800

Peter,

➢ I think we can generally agree that NAT traversal is not a corner case -- > must be solved -- no "poll" really needed for that.  

I am glad you keep this on top of the stack, since we face major problems here and without NAT traversal SIP UAs cannot function. 

How does the SIP UA configuration determine its NAT scenario without running STUN and/or STUNT tests?

One cannot bet on any NAT traversal techniques over any other (about 4-5 alternatives), because 

1. We don’t have the statistical data to make an engineering judgment, and 

2. Several techniques in combination may be required, including STUNT and port scanning as examples. 

The start of a good judgment IMHO is the development and deployment of an UDP/TCP NAT test tool as described in STUNT (the Cornell University software download) and gather statistics on the Internet as has been done by the team at Cornell under Paul Francis.

This will influence how the SIP UA should be configured. 

How high a % of call failures can we afford? How do we measure that?

Last but not least, this seems to be a running battle, analogous to the race between armor and guns of battleships and this race points to a continuous project rather than a one-time delivery.

...I know; IETF process says...

Henry

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, November 09, 2007 9:14 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Hi, 
I think we can generally agree that NAT traversal is not a corner case -- must be solved -- no "poll" really needed for that.  But I certainly agree with Sam and others here -- Config Framework needs to be progressed ASAP!!   It is waaaaaaay overdue.  Even aside from other SDOs moving ahead (which would just shoot everybody in the foot of course), real product vendors are also continuing to implement their own solutions, which can (and do) diverge from this, and become entrenched over time -- the problem only gets worse as even more time passes.     

I would counter-propose that we aggressively separate concerns, to allow Config Framework to move forward now.  In particular: 

o Outbound needs to describe usage during SUBSCRIBE (possibly other non-REGISTER cases as well).  Clearly out of scope for Config Framework.   

o Outbound or some other document should describe discovering the outbound proxy set.  It is a generic problem not specific to configuration, therefore should be out of scope for Config Framework.  Let's say that out loud in the document, and move on.   

o Markus' statement "... should be one of the basic requirements that the user MUST NOT need to manually configure such parameters as proxy addresses."  should also be declared out of scope for Config Framework itself.  It is really part of the point above (discovery of outbound proxy set).  And anyway, even if there is some still some manual configuration required in some scenarios, it becomes far simpler process with the aid of the Config Framework, so would be a major step forward.   

(Aside: On the 2nd point above, I also think outbound should not refer to config framework for this, but that's really a comment on that other document.)   

With the corrections Markus points to below (normative reference etc) and a few others we have seen, and with some cleanup to say what is out of scope (as above), plus waiting to see next rev of outbound with updates around the non-REGISTER usage (real soon now, right?!), can we agree to progress Config Framework?  (PLEASE ?!?!)   

-- Peter 

Hi,

Markus

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Nov 2007 08:26:50 -0800

At 7:24 AM -0800 11/9/07, Henry Sinnreich wrote:
>Content-class: urn:content-classes:message
>Content-Type: text/plain;
>	charset="utf-8"
>
>Peter,
>
>’ I think we can generally agree that NAT traversal is not a corner case -- > must be solved -- no "poll" really needed for that.  

<snip>

>...I know; IETF process says...

I strongly agree with Henry that the NAT traversal problem is likely to be
an ongoing problem.  One of the likely outcomes of the upcoming IPv4
address exhaustion is that multi-layered NAT (which is already present
in the network in some places) is going to become both more common
and more complicated.  Discussing NAT traversals in another context recently,
I pointed out that the intended use of STUN worked only if the only NAT
was very close to the UA (as it would be in a residential gateway NAT);
if there were multiple NATs, it failed.  The blank-looked response I got
of "why would there be multiple NATs?" scares me. 

For those who have not seen it, permit me to recommend Geoff Huston's
RIPE talk:  http://www.ripe.net/ripe/meetings/ripe-55/presentations/huston-ipv4.pdf

NB:  If you are disturbed by pictures of train wrecks, do not read this talk; he
uses a number of photographs to illustrate it.

				regards,
					Ted Hardie

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 09 Nov 2007 16:33:25 +0000

Sumanth,

Thanks for your responses. More below. I have stripped out the ones
where I am happy with your explanation.

John 

> in some cases. (The addition of a proxy does not complicate 
[JRE] We must be clear that this might not be feasible if the device is
behind a NAT or firewall. How would the NOTIFY request be routed to the
device? Although the SUBSCRIBE request will be routed based on the Via
header field (with assistance of the rport parameter), this will not be
available for a NOTIFY request (unless it does some non-standard
behaviour that probably wouldn't be available from most SIP stacks).
Even if there is no NAT/firewall and it works, I think it would apply
only prior to configuration of the outbound proxy, after which all
SUBSCRIBE requests would go through the proxy.
I think appropriate caveats should be placed against this example.

> no use for a local-network profile. 
[JRE] But then the device needs to be pre-configured to skip the
local-network profile. It would be good to avoid this.

> Event Package parameters. This has not been changed for the last few
[JRE] OK, but the authoritative proxy for the domain has to look at the
Event header field - not standard proxy behaviour. I guess a standard
proxy would still work - it would forward the SUBSCRIBE request to all
registered contacts, and all but the PDS would presumably reject the
request. But this leads to a further problem. It means a PDS has to
register with the proxy on behalf of every AoR that it serves, unless
the proxy is pre-configured with this information. These considerations
at least merit discussion.

> Operator who plans to challenge the client should allow it to 
[JRE] That's an interesting concept, and I don't recall seeing such a
concept discussed in other SIP contexts. I would like to hear more from
security experts on this.

> explicitly indicate the presence of sensitive profile data. 
[JRE] OK, so this will be fixed at profile definition time. Therefore
when the device receives the notification, even if it doesn't contain
the actual profile but only a reference, the device should still know
whether it is sensitive. Correct?
Even so, I am still a little concerned. Presumably profiles are likely
to contain a mixture of mandatory and optional information. If the
sensitive information is optional, how will the device know about that
without fetching the profile data? Or is the statement only intended to
apply when the notification actually contains the profile data, rather
than a reference?

> PDS. Perhaps we should clarify that?
[JRE] This sounds very much like the last hop exception in SIPS, which
is now being deprecated. It assumes a secure channel between the proxy
and the PDS, which I agree will often be the case, but if we are going
to make this assumption we should clearly state it and discuss the
implications in the Security Considerations section. Any opinion from
security experts?
However, consider the case of two proxies: an outbound proxy and a proxy
for the domain of the profile provider. If TLS is to the outbound proxy,
and if we assume the connection between the PDS and its domain is
secure, there is still the question of the path between the two proxies.
So it is more than just a last hop exception.

> even if we are not proposing it one way or the other? (Perhaps I am
[JRE] I certainly think we need to say something. If the device's domain
proxy and the PDS can be two different realms, the UA needs to be
configured (pre-configured in the first instance) with credentials for
the two different realms.

> why we relaxed it). Do we have other options here?
[JRE] TLS can never be "via a proxy" - it can only be "to a proxy". This
still leaves subsequent hops, e.g., from the outbound proxy to the
domain proxy for the PDS, and from there to the PDS itself. Or maybe
even more hops.
Moreover, your mention of "mutually-authenticated TLS" here rang an
alarm bell, and I searched the document for other instances of mutual
authentication. TLS mutual authentication requires a certificate at the
UA, which most UAs will not have even during normal operation, and
certainly not prior to configuration. I suspect you have in mind mutual
authentication comprising TLS server authentication and SIP digest
authentication for authenticating the client. If so, we need to be very
careful on terminology.

> understanding that this will be extended in the next revision. 
[JRE] OK, I saw the other comment on this.

---

From: [email-masked]
Date: Fri, 9 Nov 2007 12:41:11 -0500

Hi Henry (Ted also), 
Thanks for the response.  Certainly agree NAT is something to always 
consider -- there are only limited practical cases where it is not an 
issue today, at least in some way. 

BUT, I hope your comment is not intended to add work to the already very 
overdue Config Framework??   It needs to be progressed -- I hope you 
agree.  (I know you have been a very long time supporter.)  In my mind at 
least, as long as we can crack the Outbound-related issues being discussed 
(in that document, not in Framework), then there is no more needs to be 
done in Framework at this point. 

If we need to crack cases where both device and profile delivery server 
(PDS) are behind NATs, then I think it would best be described in a 
separate document at this point.  (Framework assumes that the PDS is 
reachable at least, which is a valid assumption in most realistic 
scenarios, I think.) 

To facilitate NAT traversal, I do see there may be requirements on 
*profile data* getting delivered to the device, notably in local network 
profiles, but this work is already intentionally separated from the 
framework itself. 

-- Peter

"Henry Sinnreich" <[email-masked]>
09.11.07 10:24
 
        To:     <[email-masked]>, <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: [Sipping] Summary: 
draft-ietf-sipping-config-framework-13

Peter,

➢ I think we can generally agree that NAT traversal is not a corner case 
-- > must be solved -- no "poll" really needed for that.  

I am glad you keep this on top of the stack, since we face major problems 
here and without NAT traversal SIP UAs cannot function. 

How does the SIP UA configuration determine its NAT scenario without 
running STUN and/or STUNT tests?

One cannot bet on any NAT traversal techniques over any other (about 4-5 
alternatives), because 

2. Several techniques in combination may be required, including STUNT and 
port scanning as examples. 

The start of a good judgment IMHO is the development and deployment of an 
UDP/TCP NAT test tool as described in STUNT (the Cornell University 
software download) and gather statistics on the Internet as has been done 
by the team at Cornell under Paul Francis.

Last but not least, this seems to be a running battle, analogous to the 
race between armor and guns of battleships and this race points to a 
continuous project rather than a one-time delivery.

Henry

Hi, 

-- Peter 

Hi,

Markus

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 9 Nov 2007 10:56:53 -0700

I completely agree with Peter here and Sam earlier. They both articulated the current understanding, and a way forward that would still need to address NAT related issues, esp. since those issues are not specific to the config. framework alone.

- S

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, November 09, 2007 10:41 AM
To: Henry Sinnreich
Cc: [email-masked]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Hi Henry (Ted also), 
Thanks for the response.  Certainly agree NAT is something to always consider -- there are only limited practical cases where it is not an issue today, at least in some way.   

BUT, I hope your comment is not intended to add work to the already very overdue Config Framework??   It needs to be progressed -- I hope you agree.  (I know you have been a very long time supporter.)  In my mind at least, as long as we can crack the Outbound-related issues being discussed (in that document, not in Framework), then there is no more needs to be done in Framework at this point.   

If we need to crack cases where both device and profile delivery server (PDS) are behind NATs, then I think it would best be described in a separate document at this point.  (Framework assumes that the PDS is reachable at least, which is a valid assumption in most realistic scenarios, I think.)   

To facilitate NAT traversal, I do see there may be requirements on *profile data* getting delivered to the device, notably in local network profiles, but this work is already intentionally separated from the framework itself.   

-- Peter 

09.11.07 10:24 

Peter,

Henry

Hi, 

-- Peter 

Hi,

Markus

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 9 Nov 2007 18:04:06 -0800

> but NAT traversal seems to me
> like a major point.

Yes, as mentioned, what's the use if NAT traversal does not almost
always work? And the % number has to be proven by testing on the net.

What's the use of documents that are not backed up by numbers?

My apology for repeating these points.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, November 09, 2007 7:14 AM
To: [email-masked]; [email-masked]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Hi,

Markus

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Sun, 11 Nov 2007 22:21:17 -0700

John,

Please find further responses inline. In summary, I see a few areas that
can benefit from clarity (thanks again for those suggestions) and
additional information. There are also a couple of issues (such as proxy
behavior) that have been discussed in the past. Let me know if you have
further questions or comments.

> matter for the P2PSIP group). Does it mean that UAs can contact the 
> PDS without going through a proxy? If so, say so. However, I am not 
> sure how typical this case would be. Once configured with an outbound 
> proxy (which is the norm), future SIP requests, including any 
> SUBSCRIBE or re-SUBSCRIBE requests to this package, will go through 
> the outbound proxy according to normal RFC 3261 rules. We shouldn't 
> specify anything in contradication.

> in some cases. (The addition of a proxy does not complicate the use 
> case in any way.)
[S] I see your concern. The assumption in the use case is that there is
no NAT. I can state the assumptions more clearly.

> [S] Per the assumptions listed earlier, the device is configured 
> (either pre-configuration or via a previous profile download) to only 
> request the 'device profile'. This is to illustrate a case where a 
> provider wants to support one profile that contains all the relevant 
> data and has no use for a local-network profile.
[JRE] But then the device needs to be pre-configured to skip the
local-network profile. It would be good to avoid this.
[S] The Use Case does not illustrate an out-of-the-box client obtaining
configuration. So, it need not be pre-configured with this information,
but can be configured via the initial configuration. Again, we should
state this clearly (will do).

> registered contacts for that AoR. Of course, if the user profile PDS 
> is a registered contact, it will get sent there too. Without looking 
> at the Event header field, it is impossible for a proxy to determine 
> that such a SUBSCRIBE request requires special treatment.
> request gets routed. At this point in time, it would have to look at 
> the Event Package parameters. This has not been changed for the last 
> few revisions of the I-D.
[JRE] OK, but the authoritative proxy for the domain has to look at the
Event header field - not standard proxy behaviour. I guess a standard
proxy would still work - it would forward the SUBSCRIBE request to all
registered contacts, and all but the PDS would presumably reject the
request. But this leads to a further problem. It means a PDS has to
register with the proxy on behalf of every AoR that it serves, unless
the proxy is pre-configured with this information. These considerations
at least merit discussion.
[S] I thought we had established earlier that proxies would need to look
at the Event Header. Take a look at the discussion in the WG titled "SIP
Config Framework, routing -- support in RFCs for Event package /
Presence / MWI (?)" from Feb 2007.

> The requirement to use TLS is only SHOULD, so if you don't use TLS, 
> you can never respond to an authentication challenge. This doesn't 
> make sense.

> provider-authenticated, integrity protected, channel. In other words, 
> an Operator who plans to challenge the client should allow it to use 
> TLS.
[JRE] That's an interesting concept, and I don't recall seeing such a
concept discussed in other SIP contexts. I would like to hear more from
security experts on this.
[S] I think this came up while I was reviewing things with Cullen prior
to IETF#69. We both, and the design team, agreed that this behavior
would be beneficial. However, other expert opinions are welcome.

> How does the device know which data is sensitive? Is this something 
> that has to be defined with each profile? If so, we need some 
> statement.
[JRE] OK, so this will be fixed at profile definition time. Therefore
when the device receives the notification, even if it doesn't contain
the actual profile but only a reference, the device should still know
whether it is sensitive. Correct?
Even so, I am still a little concerned. Presumably profiles are likely
to contain a mixture of mandatory and optional information. If the
sensitive information is optional, how will the device know about that
without fetching the profile data? Or is the statement only intended to
apply when the notification actually contains the profile data, rather
than a reference?
[S] The requirement applies only when it contains the actual profile
data. And we allow for such notifications to contain redirection to a
PCC that can provide secure profiles via indirection. (And yes, the
client can know if it can expect sensitive profile data; but cannot know
for certain until it obtains the profile data.)

> This only works if the TLS session is end-to-end, i.e., no proxy 
> between the UA and the PDS. If there is a proxy, it is only the proxy 
> that is authenticated, not the PDS.

> the DNS resolution using the domain name lead to the proxy in the 
> first place). Thus, an authenticated channel with the next-hop (PDS or

> proxy) is presented as equivalent to authentication of the provider. 
> In the case that this is a proxy, I agree that it does not 
> authenticate the PDS. Perhaps we should clarify that?
[JRE] This sounds very much like the last hop exception in SIPS, which
is now being deprecated. It assumes a secure channel between the proxy
and the PDS, which I agree will often be the case, but if we are going
to make this assumption we should clearly state it and discuss the
implications in the Security Considerations section. Any opinion from
security experts?
However, consider the case of two proxies: an outbound proxy and a proxy
for the domain of the profile provider. If TLS is to the outbound proxy,
and if we assume the connection between the PDS and its domain is
secure, there is still the question of the path between the two proxies.
So it is more than just a last hop exception.
[S] Agree. And perhaps this can be clarified. However, there is no way
for the device to confirm the presence, or absence, of security between
proxies, and hence the use of SIPS.

> There needs to be some discussion about realm. Does the PDS 
> necessarily use the same realm that the device uses with its domain 
> proxy/registrar?

> to be the same (tho' it can be). Do we necessarily need to specify 
> this, even if we are not proposing it one way or the other? (Perhaps I

> am missing something?)
[S] Agree. And while there is some mention of credentials, we can make
this clear.

> The use of TLS is not necessarily a substitute for this, unless the 
> TLS session is end-to-end, not via a proxy.
> [S] If the mutually-authenticated TLS is via a proxy that belongs to 
> the Provider, then the device is asked to trust the connection (not my

> first choice). If we do not want to trust the proxy, we can use SIP 
> Identity for authentication, but not privacy. In other words, the PDS 
> would need to include the SIP Identity in all cases that it does not 
> directly speak to a device via mutually-authenticated TLS. I am OK 
> with that (unsure why we relaxed it). Do we have other options here?

[S] Firstly, apologies. I meant to say '...if the connection to the PDS
is via a proxy, and the mutually-authenticated TLS is established with
such a proxy..."

[S] There are two ways to perform mutual authentication. Firstly, via
Server-authenticated TLS and digest authentication as you indicated, or
using PKI (e.g., cable clients and operators have root CA certificates
that can be used for mutual authentication out-of-the-box).

The I-D specifies the former and this is explained in 5.2.1
"Authentication of the identity requesting the profile is accomplished
by the PDS by using the Digest Authentication mechanism, over TLS". (We
could make this clear, if it is not.) The latter is left as a future
extension when we discuss cert-based authentication. 

- S

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 Nov 2007 08:22:52 +0000

Sumanth,

More on just a couple of points.
> would be beneficial. However, other expert opinions are welcome.
[JRE] Perhaps the security considerations section should explain the
rationale.

> >    transmitted on the mutually authenticated TLS session 
> established 
> > for
[JRE] The original text that I queried: "If this initial notification
was transmitted on the mutually authenticated TLS session established
for enrollment requests, then it is considered authenticated" is still
wrong or at least misleading. A TLS session (connection) is between the
UA and its local (outbound) proxy, which is not necessarily the domain
proxy for the PDS. The local proxy can send inbound requests to the UA
over an existing TLS connection (in the context of sip-outbound). This
is not limited to NOTIFY requests for profile delivery purposes, but any
inbound request. So suppose the UA uses sip-outbound to establish a TLS
connection and register with its local proxy. The it uses that same TLS
connection to deliver the SUBSCRIBE request for profile delivery
enrollment. Then it receives a NOTIFY request from the PDS on that same
connection. Why is "it" (I assume it means the PDS) "considered
authenticated"? Any requests can arrive over this TLS session.

> extension when we discuss cert-based authentication. 
[JRE] Unless we define mutual authentication as meaning this, many
people might think of TLS mutual authentication.

---

From: <[email-masked]>
Date: Mon, 12 Nov 2007 10:25:57 +0200

Hi Peter,

In general I agree with your proposal. I'd still like to see a version
of Outbound that deals with SUB before REG in a consistent manner of
what is written in config-framework, and perhaps then we are done. (I
hope we get this by next Monday.) The Outbound proxy discovery problem
will still remain, but we might solve the initial discovery by some
other means than SUB/NOT. Some more below:

Peter Blatherwick wrote:
>	o Outbound needs to describe usage during SUBSCRIBE (possibly
other non-REGISTER cases as
> well).  Clearly out of scope for Config Framework.

I agree, and I believe we got an agreement from Outbound editors to do
this as well. But since this gets into the details such as where 'ob'
parameter is included, I think it would be good to see at least one
version of Outbound where this functionality is included, before
declaring that everuthing will work wrt. config-framework. If this
becomes reasonably clear, it is fine with me to proceed with
config-framework without waiting for the total completion of Outbound.

>	o Outbound or some other document should describe discovering
the outbound proxy set.  
> It is a generic problem not specific to configuration, therefore
should be out of scope for 
> Config Framework.  Let's say that out loud in the document, and move
on.   

This I'm a bit more uncomfortable with. The outbound proxy (set) seems
to me like the most important piece of configuration the UA needs. It
would be weird for IETF to come up with UA configuration framework that
does not tell how that gets configured, and won't be able to reference
any other means to do so either. (I'm refering to a basic residential
scenario here where there isn't often any "local network" profile on
UA's side of NAT to bootstrap from.) But it maybe that the SUB/NOT
paradigm is not the best for this, so perhaps we need another separate
solution. Simple DNS NAPTR/SRV has been proposed earlier, but not really
favoured either. But some kind of automated solution is definitely
needed. 
	
>	o Markus' statement "... should be one of the basic requirements
that the user MUST NOT 
> need to manually configure such parameters as proxy addresses."
should also be declared 
> out of scope for Config Framework itself.  It is really part of the
point above (discovery of
> outbound proxy set).  And anyway, even if there is some still some
manual configuration 
> required in some scenarios, it becomes far simpler process with the
aid of the Config 
> Framework, so would be a major step forward. 

True. For instance in a Nokia SIP UA there are probably over 30 distinct
parameters that are possible to configure. I don't have a clue which
ones are really used (by service providers, users definitely won't know
what to do), I suppose the default value works fine in most cases. There
are only few mandatory settings, such as the Outbound proxy address,
would be nice to have a solution there...

Markus

	From: ext [email-masked]
[mailto:[email-masked]] 
	Sent: 09 November, 2007 17:14
	To: Isomaki Markus (Nokia-SIR/Espoo)
	Cc: [email-masked]; [email-masked]
	Subject: RE: [Sipping] Summary:
draft-ietf-sipping-config-framework-13

	Hi, 
	I think we can generally agree that NAT traversal is not a
corner case -- must be solved -- no "poll" really needed for that.  But
I certainly agree with Sam and others here -- Config Framework needs to
be progressed ASAP!!   It is waaaaaaay overdue.  Even aside from other
SDOs moving ahead (which would just shoot everybody in the foot of
course), real product vendors are also continuing to implement their own
solutions, which can (and do) diverge from this, and become entrenched
over time -- the problem only gets worse as even more time passes.     
	
	I would counter-propose that we aggressively separate concerns,
to allow Config Framework to move forward now.  In particular: 
	
	o Outbound needs to describe usage during SUBSCRIBE (possibly
other non-REGISTER cases as well).  Clearly out of scope for Config
Framework.   
	
	o Outbound or some other document should describe discovering
the outbound proxy set.  It is a generic problem not specific to
configuration, therefore should be out of scope for Config Framework.
Let's say that out loud in the document, and move on.   
	
	o Markus' statement "... should be one of the basic requirements
that the user MUST NOT need to manually configure such parameters as
proxy addresses."  should also be declared out of scope for Config
Framework itself.  It is really part of the point above (discovery of
outbound proxy set).  And anyway, even if there is some still some
manual configuration required in some scenarios, it becomes far simpler
process with the aid of the Config Framework, so would be a major step
forward.   
	
	(Aside: On the 2nd point above, I also think outbound should not
refer to config framework for this, but that's really a comment on that
other document.)   
	
	With the corrections Markus points to below (normative reference
etc) and a few others we have seen, and with some cleanup to say what is
out of scope (as above), plus waiting to see next rev of outbound with
updates around the non-REGISTER usage (real soon now, right?!), can we
agree to progress Config Framework?  (PLEASE ?!?!)   
	
	-- Peter

---

From: [email-masked]
Date: Mon, 12 Nov 2007 11:55:06 -0500

Hi Markus,
Good, we are getting closer then. 

>> the outbound proxy set.  It is a generic problem not specific 
>> to configuration, therefore should be out of scope for 
>> Config Framework.  ...
>
> This I'm a bit more uncomfortable with.  The outbound proxy 
> (set) seems to me like the most important piece of 
> configuration the UA needs.

I do agree, the proxy is obviously a key piece.  However, I just do not 
see this is specific to the Config Framework itself, so to me really wants 
to be treated as a separate issue to address (in a different draft).  Even 
if the device already is fully configured with all other needed data (say 
it is all sufficiently defaulted as you point to below), the outbound 
proxy still needs to be discovered just to make a call.  Even if Config 
Framework were to solve this issue, then how would it apply to other 
scenarios not related to initial configuration or configuration updating? 
To me, Config Framework is about methods to exchange config data held on a 
server, and to support that we need to be able to discover the 
configuration servers specifically.  But discovery of outbound proxy is 
much more general than that.  And, I do not see any reason to expect that, 
given some general means to discover the outbound proxy, there would be 
any real change in Config Framework to work with that. 

To be honest, it is not really clear to me that a general solution to this 
is even possible.  In the most general case, the proper outbound proxy to 
use could be anywhere on the Internet, and completely unrelated to the 
device or the network it is connecting to in any way, so seems to me the 
user is going to need to enter something.  Trick is to make that something 
as painless and error-free as possible. 

Perhaps what we should be pushing for is a SIPPING WG item to specifically 
address discovery of outbound proxy, or that it get included in Outbound 
work already underway?  (I think i would not favour the latter, since 
Outbound is also waaaaaaaay overdue.) 

> ... Nokia SIP UA there are probably over 30 distinct
> parameters that are possible to configure

Only 30??  Then what are we worried about ??  >:^) 

-- Peter

<[email-masked]>
12.11.07 03:25
 
        To:     <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: [Sipping] Summary: 
draft-ietf-sipping-config-framework-13

Hi Peter,

the outbound proxy set. 
on. 

that the user MUST NOT 
should also be declared 
manual configuration 
aid of the Config 

Markus

                 Hi, 
                 I think we can generally agree that NAT traversal is not 
a
 
                 I would counter-propose that we aggressively separate 
concerns,
to allow Config Framework to move forward now.  In particular: 
 
                 o Outbound needs to describe usage during SUBSCRIBE 
(possibly
other non-REGISTER cases as well).  Clearly out of scope for Config
Framework. 
 
                 o Outbound or some other document should describe 
discovering
the outbound proxy set.  It is a generic problem not specific to
configuration, therefore should be out of scope for Config Framework.
Let's say that out loud in the document, and move on. 
 
                 o Markus' statement "... should be one of the basic 
requirements
 
                 (Aside: On the 2nd point above, I also think outbound 
should not
refer to config framework for this, but that's really a comment on that
other document.) 
 
                 With the corrections Markus points to below (normative 
reference
 
                 -- Peter

---

From: David Robbins <[email-masked]>
Date: Tue, 13 Nov 2007 16:12:06 -0500

I'm generally pretty comfortable with draft -13.

There remain a number of points that could be clarified or otherwise  
addressed, some of which other commenters have noted. As others have  
noted, it is highly desirable to advance this draft -- it's been a  
long time in the making, and the longer it waits, the less relevant  
it will be. Yet, we don't want to rush it to completion if it still  
has some issues that must be addressed in order for it to be useful.

I'll note a few points that could use more work, though I'm not ready  
to claim that any of these should prevent the draft from being advanced.

Section 5.3.2 discusses various timeouts. I noted in my July comments  
that HTTP and HTTPS do not specify a timeout, so for profile  
retrieval by either of those schemes, there exists no standardized  
timeout. Similarly, I noted that RFC 3265 does not specify a timeout  
to be applied to the receipt of the mandatory NOTIFY following a  
successful SUBSCRIBE request. Here, the configuration framework  
refers to such a timeout, but the existence and duration of such a  
timeout is not standardized. The framework draft seems to imply that  
there are well-known and standardized timeouts for both these cases,  
but that is not the case, AFAIK.

As others have noted, the draft is rather vague about how one goes  
about determining whether all three standardized profiles will be  
used, and whether and in what sequence additional profiles might be  
required. Given the variety of deployment scenarios that this  
framework is meant to support, and the deferral of profile content to  
other documents, it is understandable that this draft can't say too  
much. But it would perhaps be helpful for this document to be more  
explicit about how the set and sequence of profiles is determined --  
at least to say something like the default set is the three  
standardized profile in the sequence indicated, but within any  
profile data may be included to alter the set and sequence of  
subsequent profiles.

John Elwell points out the potential deadlock regarding retrieval of  
a root CA certificate by which subsequent TLS connections can be  
validated. In our implementation of this framework, I was not  
comfortable with the notion of embedding the certificate in the first  
profile retrieved, because I wanted to be able to secure the  
retrieval of the first profile. I was willing to allow unsecured  
retrieval only of the certificate itself (because the cert is self- 
validating, and if you get a bogus cert, you won't be able to  
validate your connection to the PDS or PCC). My solution was to  
define a separate subscription for the sole purpose of downloading  
the certificate; this is the first item retrieved via the framework.  
This wouldn't apply to all deployment scenarios, of course -- in  
some, perhaps many, cases, you'd use a well-known root cert. Can this  
draft at least be said to permit the retrieval of a cert in some  
fashion prior to retrieval of the local network profile? Should the  
issue be more explicitly addressed in the draft?

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 18:02:15 +0200

Hi Peter,
 
See inline starting with [Markus]

	Sent: 12 November, 2007 18:55

	Hi Markus, 
	
discovering

	> configuration the UA needs. 
	
	I do agree, the proxy is obviously a key piece.  However, I just
do not see this is specific to the Config Framework itself, so to me
really wants to be treated as a separate issue to address (in a
different draft).   
	 
	[Markus] OK, maybe I just need to give up and accept the
situation that even if we one day complete config-framework and
sip-outbound, we still have to define a separate mechanism for outbound
proxy discovery, or then rely on manual configuration (or special cases
where there's no NAT between UA and PDS). Perhaps this is the best
approach if we believe we can otherwise complete those two important
specs in the immediate future. Then those two specs just need to make
the situation clear. 
	 
	Even if the device already is fully configured with all other
needed data (say it is all sufficiently defaulted as you point to
below), the outbound proxy still needs to be discovered just to make a
call.  Even if Config Framework were to solve this issue, then how would
it apply to other scenarios not related to initial configuration or
configuration updating?   
	 
	[Markus] I would think that typically if a UA/user gets a set of
Outbound proxies, it would then use that set and sip-outbound mechanisms
for all of its SIP traffic. So we just need some mechanism to get that
set.
	 
	To me, Config Framework is about methods to exchange config data
held on a server, and to support that we need to be able to discover the
configuration servers specifically.  But discovery of outbound proxy is
much more general than that.  And, I do not see any reason to expect
that, given some general means to discover the outbound proxy, there
would be any real change in Config Framework to work with that.    
	 
	[Markus] Agree. 
	
	To be honest, it is not really clear to me that a general
solution to this is even possible.  In the most general case, the proper
outbound proxy to use could be anywhere on the Internet, and completely
unrelated to the device or the network it is connecting to in any way,
so seems to me the user is going to need to enter something.  Trick is
to make that something as painless and error-free as possible.  
	 
	[Markus] I think this is the principal case we should consider.
It is clear that the UA needs *something* to start with. In case of
outbound proxy discovery the domain, which can be derived from user's
AoR should be enough. Overall we should aim at configuration solution
where the user only needs to input their AoR and digest password, and
everything else should come automatically. With config-framework alone
it seems this can't be accomplished, so we need a separate mechanism for
outbound proxy discovery.   
	
	Perhaps what we should be pushing for is a SIPPING WG item to
specifically address discovery of outbound proxy, or that it get
included in Outbound work already underway?  (I think i would not favour
the latter, since Outbound is also waaaaaaaay overdue.)  
	 
	[Markus] Probably a separate draft is then the most realistic
option.      

	 
	[Markus] The problem seems to be that there are even some
networks which are so broken that it is not possible to send anything
with SIP before fixing some of these parameters in the UA... Hopefully
this stuff gets fixed by the time config-framework gets introduced.     
	
	-- Peter 
	
	 Markus

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Nov 2007 16:08:38 -0500

Perhaps I am in the minority here, but I don't see how this mechanism scales, when it requires a permanent lifetime subscription to each PDS.  You're talking about a permanent TLS connection from every subscriber to each PDS server, with TCP keepalive or CRLF refreshes (ie, outbound) *forever* just so the PDS can tell the subscriber to change its config once a year??  Don't get me wrong, I don't mind selling more equipment, but I don't think too many operators will want to pay for that.  Is there truly a need for direct asynchronous modification of config from each PDS to the UAC?  Isn't it really that the operator just needs to have a way to reset the UAC? (I.e., tell it to start its config cycle again)  That could be done another way I think.

-hadriel
p.s. also the decision of how long the subscription should be is essentially on the wrong side - it's the PDS that knows whether it will ever need/want to change configs asynchronously, not the UA.

> Sent: Friday, October 26, 2007 11:59 AM
> To: [email-masked]
> A new version (-13) of the SIP Configuration Framework is now available.
>
>
> I did not include changes that were already agreed upon in previous IETF

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 14 Nov 2007 14:18:44 -0700

Hadriel,

The default behavior specified here is the way a UA obtains the profile
data it requires, in the absence of any pre-configuration. The profile
data can modify some of the parameters, like required profiles or change
notification requests, once it has successfully obtained it.

Regarding maintaining subscriptions, there is nothing that prohibits you
from obtaining a profile "once" (expires=0) and indicating that you are
not interested in change notifications. In such cases, if you need to
provide changes (say six months later), you are free to use other
mechanisms to reset the device or just obtain a new "one-time"
subscription.

Regarding who decides on the subscription duration, that behavior is
specified in 3265, this document just follows those requirements. (If
you want to change the UA's idea of what it needs to ask for, specify it
in the profile data.)

- S

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 2:09 PM
To: Sumanth Channabasappa; [email-masked]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13 

Perhaps I am in the minority here, but I don't see how this mechanism
scales, when it requires a permanent lifetime subscription to each PDS.
You're talking about a permanent TLS connection from every subscriber to
each PDS server, with TCP keepalive or CRLF refreshes (ie, outbound)
*forever* just so the PDS can tell the subscriber to change its config
once a year??  Don't get me wrong, I don't mind selling more equipment,
but I don't think too many operators will want to pay for that.  Is
there truly a need for direct asynchronous modification of config from
each PDS to the UAC?  Isn't it really that the operator just needs to
have a way to reset the UAC? (I.e., tell it to start its config cycle
again)  That could be done another way I think.

-hadriel
p.s. also the decision of how long the subscription should be is
essentially on the wrong side - it's the PDS that knows whether it will
ever need/want to change configs asynchronously, not the UA.

available.
Elwell,
note,
IETF

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Nov 2007 16:45:19 -0500

Ahh - the profile data can change the config-framework behavior itself.  Didn't think of that.  OK, got it.  Thanks!
-hadriel

> Sent: Wednesday, November 14, 2007 4:19 PM
> To: Hadriel Kaplan; [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 29 Nov 2007 19:37:36 -0800

I assume that connection could be the same one that used for the  
incoming SIP calls.  Many of the SP I have talked to have had pretty  
strong requirements around being able to quickly roll out a new  
version of software to all their UAs if a security bug was  
discovered  that allowed people to make expensive calls that the SP  
could not bill for. When the UA is behind a NAT this typically  
implies either frequent messaging or persistent connections (or both).

Cullen <with my individual hat on>

On Nov 14, 2007, at 1:08 PM, Hadriel Kaplan wrote:

> Perhaps I am in the minority here, but I don't see how this  
> mechanism scales, when it requires a permanent lifetime  
> subscription to each PDS.  You're talking about a permanent TLS  
> connection from every subscriber to each PDS server, with TCP  
> keepalive or CRLF refreshes (ie, outbound) *forever* just so the  
> PDS can tell the subscriber to change its config once a year??   
> Don't get me wrong, I don't mind selling more equipment, but I  
> don't think too many operators will want to pay for that.  Is there  
> truly a need for direct asynchronous modification of config from  
> each PDS to the UAC?  Isn't it really that the operator just needs  
> to have a way to reset the UAC? (I.e., tell it to start its config  
> cycle again)  That could be done another way I think.
>
> -hadriel
> essentially on the wrong side - it's the PDS that knows whether it  
> will ever need/want to change configs asynchronously, not the UA.
>
>