Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 14:09:36 +0200

Hi Robert,

This reply addresses your comment regarding the IANA registration template/procedure, and the major issues.

> Summary: There are a few issues to address before progressing to IETF LC. I'm putting the document into revised ID needed to address at least the IANA points below.
>
> The primary issue is with the instructions to IANA on creating the new trees and the registration template used to put things in those trees.
>
> Sections 7.3.2 and 7.3.3 don't currently define the format of an entry in the trees in the new subregistry. This needs to be clearly defined, and the sections need to explicitly indicate that the trees are initially empty.

I suggest to add the following text to the end of sections 7.3.2 and 7.3.3:

	"The format of the [global/SIP] tree is as described below:

	Decimal      Name   Description   Reference
	---------------------------------------------------

	Decimal contains an integer value, incremented by IANA every time a new feature capability indicator is added to the table. 

	Name contains the Feature Capability Indicator Name, provided in the registration feature capability indication registration template.

	Description contains the Abstract, provided in the registration feature capability indication registration template.

	Reference contains the Feature Capability Indicator Specification Reference, provided in the registration feature capability indication registration template."

----------------

> The template in section 8 was adapted from RFC2506, but it needs more tweaks and it needs to match whatever format is defined above.
>
>   * We don't need a separate list for reviewing these requests. We certainly don't need a list at apps.ietf.org. The normal process for submitting a request for the global tree should be submitting the template by email to [email-masked], and for the sip 
> tree, the normal process would be submitting an Internet-Draft to the IESG.

I suggest the following change:

OLD:

   	"To: [email-masked]
   	(feature capability indicators mailing list)
   	Subject: Registration of feature capability indicator XXXX"

NEW:

 	"Registration requests for the global tree are submitted by e-mail to [email-masked].
	Registration requests for the sip tree requires submitting an Internet-Draft to the IESG."

----------------

>   * IANA is currently using a different for media feature tag registrations. It's available at <http://www.iana.org/protocols/media-feature-tag-template.txt>. If we really need to follow that registration format, please start from this template. But do we 
> need all this information in the registry?

I did start from the media feature tag template, and then removed stuff :)

However, I do agree that not all of the remaining stuff needs to be in the template. Unlike media feature tags, we do mandate a reference to a specification for feature capability indicators, so whatever information that IANA doesn't need can be put in that specification.

So, my suggestion would be that the registration template would look like this:

   	"| Instructions are preceded by '|'.  All fields are mandatory.

   	Feature capability indicator name:

   	Description:

   	| The description should be no longer than 4 lines. More
   	| detailed information can be provided in the feature
   	| capability indicator specification.

   	Feature capability indicator name:

   	| The referenced specification MUST contain the information
   	| listed in Section 5.3 of XXXX (IANA: Replace XXXX with
   	| assigned RFC number of this specification.

   	Contact:

   	| Name(s) & email address(es) of person(s) to
   	| contact for further information."

The following information would be in the feature capability indication specification:

5.3.  Feature Capability Indicator Specification Requirements

5.3.1.  General

   A feature capability indicator specification MUST address the issues
   defined in the following subsections, or document why an issue is not
   applicable for the specific feature capability indicator.  A
   reference to the specification MUST be provided when the feature
   capability indicator is registered with IANA (see Section 8).

   It is bad practice for feature capability indicator specifications to
   repeat procedures (e.g. general procedures on the usage of the
   Feature-Caps header field and feature capability indicators) defined
   in this specification, unless needed for clarification or emphasis
   purpose.  A feature capability indicator specification MUST NOT
   modify the Feature-Caps header field rules and semantics defined in
   Section 4.

   A feature capability indicator specification MUST NOT weaken any
   behavior designated with "SHOULD" or "MUST" in this specification.
   However, a specification MAY strengthen "SHOULD", "MAY", or
   "RECOMMENDED" requirements to "MUST" strength if features and
   capabilities associated with the SIP feature capability indicator

5.3.2.  Overall Description

   The feature capability indicator specification MUST contain an
   overall description of the feature capability indicator: how it is
   used to indicate support of a feature, a description of the feature
   associated with the SIP feature cap, a description of any additional
   information (conveyed using one or more feature capability indicator
   values) that can be conveyed together with the feature capability
   indicator, and a description of how the associated feature may be
   exercised/invoked.

5.3.3.  Feature Capability Indicator Values

   A feature capability indicator can have an associated value, or a
   list of values.

   The feature capability indicator specification MUST define the syntax
   and semantics of any value defined for the feature capability
   indicator, including possible restrictions related to the usage of a
   specific value.  The feature capability indicator specification MUST 
   define the value(s) in accordance with the ABNF defined in Section
   6.3.2. The feature capability indicator specification MUST define
   the default value, if applicable.

   If not values are defined for the feature capability indicator, it MUST
   be indicated in the feature capability indicator specification.

   A feature capability indicator value is only applicable for the
   feature capability indicator for which it has been defined.  For
   other feature capability indicators, the value has to be defined
   explicitly, even if the semantics are identical.

   It is strongly RECOMMENDED to not re-use a value that already has
   been defined for another feature capability indicator, unless the
   semantics of the values are the same.

5.3.4.  Usage Restrictions

   If there are restrictions on how SIP entities can insert a feature 
   capability indicator, the feature capability indicator specification MUST
   document such restrictions.

   There might be restrictions related to whether entities are allowed
   to insert a feature capability indicator in registration related
   messages, standalone transaction messages, or dialog related
   messages, whether entities are allowed to insert a feature capability
   indicator in requests or responses, whether entities also need to
   support other features and capabilities in order to insert a feature
   capability indicator, and whether entities are allowed to indicate
   support of a feature in conjunction with another feature.

5.3.5.  Interoperability Considerations

  If there are specific interoperability considerations that apply to the 
  feature capability indicator, the feature capability indicator specification
  MUST document such considerations.

5.3.6.  Security Considerations
	
  If there are specific security considerations that apply to the feature
  capability indicator, the feature capability indicator specification
  MUST document such considerations.

5.3.7.  Examples

   It is RECOMMENDED that the feature capability indicator specification
   provide demonstrative message flow diagrams, paired with complete
   messages and message descriptions.

   Note that example message flows are by definition informative, and do
   not replace normative text.

5.3.8.  Other Information

   If there is additional information about the feature capability indicator,
   it is RECOMMENDED to describe such information. It can include e.g.
   names of related feature capability indicators."

Other major issues:
-----------------------------------------

> 1) Should the expert reviewer be explicitly required to consider security issues as part of that review? (see section 4.6 of <https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/>
> for example).

Per my suggestion above, about moving 'Security considerations' from the template into the feature capability indicator specification, I guess the expert reviewer would also look at the Security Considerations. I don't think we need to explicitly say anything.

----------------

> 2) The security considerations section claims that the aspects of the considerations in rfc3840 that apply to end user devices don't apply here since these are not typically used to convey information about end user devices. "Not typically" is weak. Can this > sentence be made more specific about what concerns do and don't apply? The concerns in 3840 about influencing application behavior, and in 2506 about providing information that can be used to exploit implementation weakeness at the elements that > do provide these tags should be reflected here.

I suggest some additional security considerations text:

"9.  Security Considerations

   The security issues for feature capability indicators are similar to
   the ones defined in RFC 3840 for media feature tags.  Media
   feature tags can reveal information about end-users and end-user 
   equipment, which can be used for industrial espionage. The knowledge
   about end-user equipment capabilities can also be used to influence
   application behavior. As feature capability indicators are not intended  
   to convey  capability information of end-user devices, such end-user 
   security aspects of   RFC 3840 do not apply to feature capability indicators.

   In addition, the RFC 3840 security issue regarding an attacker using
   the SIP caller preferences extension [RFC3841] in order to affect
   routing decisions does not apply, as the mechanism is not defined to
   be used with feature capability indicators.

   Feature capability indicators can, however, provide capability and 
   characteristics information about the SIP entity, some of which might
   be sensitive.  The Feature- Caps header field does not convey address 
   information about SIP entities.  However, individual feature capability 
   indicators might provide address information as feature capability indicator
   values. Therefore, mechanisms for guaranteeing confidentiality and
   authenticity SHOULD be provided."

----------------

>3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in section 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE 
>will get back to the UA that sent the subscribe. The information that creates the other dialogs for it must appear in the immediate 
>NOTIFYs. Is there a requirement for the end accepting a subscription to use the same feature capabilities in the 200 OK to the subscription 
>and in the immediate NOTIFY?

I suggest the following new note to section 4.3.2.

   	"NOTE: As it cannot be guaranteed that 2xx responses associated with
   	SIP SUBSCRIBE requests will reach the UAC, due to forking of the request,
	entities need to indicate supported features and capabilities in the SIP NOTIFY 
	request that will be sent for each of the created subscription dialogs."

I don't think we need to mandate the capabilities in the 200 OK (if inserted in the first place) need to be identical to the NOTIFY. As the NOTIFY is a target refresh request, it is allowed to indicate different capabilities.

----------------

> 4) Similarly, consider clarifying whether UPDATES nested within an INVITE constrained to keep the same feature capability indicators as in the INVITE?

Again, as UPDATEs are target refresh requests (even when nested within an INVITE), they can indicate a new set of supported capabilities.

Note that the indication of supported features is not "offer/answer" - the support is indicated independently in each direction.

----------------

Thanks!

Regards,

Christer

---

From: Brett Tate <[email-masked]>
Date: Wed, 22 Aug 2012 05:19:30 -0700

> >3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in
> section 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE
> >will get back to the UA that sent the subscribe. The information that
> creates the other dialogs for it must appear in the immediate
> >NOTIFYs. Is there a requirement for the end accepting a subscription
> to use the same feature capabilities in the 200 OK to the subscription
>  entities need to indicate supported features and capabilities in 
>  the SIP NOTIFY request that will be sent for each of the created 
>  subscription dialogs."
> 
> I don't think we need to mandate the capabilities in the 200 OK 
> (if inserted in the first place) need to be identical to the 
> NOTIFY. As the NOTIFY is a target refresh request, it is allowed 
> to indicate different capabilities.

Based upon the current wording of draft-ietf-sipcore-proxy-feature-05 section 4.3.2, the feature-caps within the initial SUBSCRIBE's 2xx (or deprecated 18x) appears irrelevant from subscriber's perspective since the response does not appear to create a dialog.

RFC 6665 is a little ambiguous concerning if SUBSCRIBE's 2xx actually creates a dialog.  From notifier perspective, it looks like sending 2xx does indicate that the dialog usage was created.  However from a subscriber perspective, it looks like receiving the 2xx no longer creates a dialog.

RFC 6665 section 4.2.1.1

"Once the notifier determines that it has enough information to create
 the subscription (i.e., it understands the event package, the
 subscription pertains to a known resource, and there are no other
 barriers to creating the subscription), it creates the subscription
 and a dialog usage, and returns a 200 (OK) response."

RFC 6665 section 4.4.1:

"Dialogs usages are created upon completion of a NOTIFY transaction
 for a new subscription, unless the NOTIFY request contains a
 "Subscription-State" of "terminated."

 Because the dialog usage is established by the NOTIFY request, the
 route set at the subscriber is taken from the NOTIFY request itself,
 as opposed to the route set present in the 200-class response to the
 SUBSCRIBE request."

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 14:21:21 +0200

Hi Brett,

Please see the note text I suggested in my reply to Robert.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: 22. elokuuta 2012 15:20
To: [email-masked]; [email-masked]
Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues

> SIP SUBSCRIBE requests will reach the UAC, due to forking of the 
> request,  entities need to indicate supported features and 
> capabilities in  the SIP NOTIFY request that will be sent for each of 
> the created  subscription dialogs."
> 
> I don't think we need to mandate the capabilities in the 200 OK (if 
> inserted in the first place) need to be identical to the NOTIFY. As 
> the NOTIFY is a target refresh request, it is allowed to indicate 
> different capabilities.

RFC 6665 section 4.2.1.1

"Once the notifier determines that it has enough information to create  the subscription (i.e., it understands the event package, the  subscription pertains to a known resource, and there are no other  barriers to creating the subscription), it creates the subscription  and a dialog usage, and returns a 200 (OK) response."

RFC 6665 section 4.4.1:

"Dialogs usages are created upon completion of a NOTIFY transaction  for a new subscription, unless the NOTIFY request contains a  "Subscription-State" of "terminated."

 Because the dialog usage is established by the NOTIFY request, the  route set at the subscriber is taken from the NOTIFY request itself,  as opposed to the route set present in the 200-class response to the  SUBSCRIBE request."
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brett Tate <[email-masked]>
Date: Wed, 22 Aug 2012 05:45:44 -0700

> > "NOTE: As it cannot be guaranteed that 2xx responses 
> > associated with SIP SUBSCRIBE requests will reach the 
> > UAC, due to forking of the request,  entities need to 
> > indicate supported features and capabilities in the 
> > SIP NOTIFY request that will be sent for each of

Good enough for me.  However, my understanding is that the SUBSCRIBE 2xx comment is relevant to RFC 3265 compliant subscribers instead of RFC 6665 compliant subscribers.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Aug 2012 13:19:01 -0400

A couple of comments now. Maybe more when I have more time to think 
about it:

> 	Decimal      Name   Description   Reference

Why? What value does this integer have?

> Again, as UPDATEs are target refresh requests (even when nested within an INVITE), they can indicate a new set of supported capabilities.

Consider:

INVITE
1xx INVITE
UPDATE
200 UPDATE
200 INVITE

(Regardless of the direction of the UPDATE)

Do the P-F values in the 200 INVITE override those from the UPDATE or 
its response?

In theory the 200 UPDATE and 200 INVITE can be received out of order. 
And proxies that are including P-F may not be stateful about this, so 
that they can only indicate their state at the time the message goes by.

I don't see what could be done about it. In most cases it won't matter 
what the order is.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 20:35:51 +0200

Hi,

> Why? What value does this integer have?

It's just a "row number". Most media feature tag tables seem to have it, so that's why I added it...

I didn't even check whether it's part of the associated registration templates, or whether IANA adds it by default.

>I don't see what could be done about it. In most cases it won't matter

I agree, because I think the indicated features will be the same in these messages.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Aug 2012 16:00:57 -0500

Hi Christer -

This all looks good to me (except for a further comment on the Security 
Considerations section inline).

> 	Decimal      Name   Description   Reference
But they are conveying the capability information for intermediaries, 
and the
concerns about exploiting knowing about what features that intermediary 
supports,
particularly exploiting known implementation weaknesses in the 
implementation of
that feature do apply.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 23:09:13 +0200

Hi,

> This all looks good to me (except for a further comment on the Security Considerations section inline).

>>> 2) The security considerations section claims that the aspects of the considerations in rfc3840 
>>> that apply to end user devices don't apply here since these are not typically used to convey 
>>> information about end user devices. "Not typically" is weak. Can this sentence be made more 
>>> specific about what concerns do and don't apply? The concerns in 3840 about influencing application 
>>> behavior, and in 2506 about providing information that can be used to exploit implementation weakeness 
>>> at the elements that do provide these tags should be reflected here.
> But they are conveying the capability information for intermediaries, and the concerns about 
> exploiting knowing about what features that intermediary supports, particularly exploiting 
> known implementation weaknesses in the implementation of that feature do apply.

I am trying to cover that in the 3rd paragraph (below).

I guess I could move that text up, if it helps.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 22 Aug 2012 16:22:26 -0500

> I guess I could move that text up, if it helps.
I don't think "might be sensitive" raises the reader's level of 
awareness sufficiently.

How about adding "Malicious elements viewing the indicators may be able 
to discern
application deployment details or identify elements with exploitable feature
implementation weaknesses." after that first sentence, leaving the 
paragraph where it is?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Aug 2012 08:04:16 +0200

Hi,

>I don't think "might be sensitive" raises the reader's level of awareness sufficiently.
>
> to discern application deployment details or identify elements with exploitable feature
> implementation weaknesses." after that first sentence, leaving the paragraph where it is?

Sounds good. So, something like:

     Feature capability indicators can, however, provide capability and
     characteristics information about the SIP entity, some of which might
     be sensitive. Malicious elements viewing the indicators may be able
     to discern application deployment details or identify elements with 
     exploitable feature implementation weaknesses. The Feature-Caps 
     header field does not convey address information about SIP entities.  
     However, individual feature capability indicators might provide address 
     information as feature capability indicator values. Therefore, mechanisms 
     for guaranteeing confidentiality and authenticity SHOULD be provided."

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Aug 2012 08:21:12 +0200

Hi,

>        | contact for further information."

The fci specification reference will of course also be part of the template:

     "Feature capability indicator specification reference:   

     | The referenced specification MUST contain the information 
     | listed in Section 5.3 of XXXX (IANA: Replace XXXX with 
     | assigned RFC number of this specification."

Regards,

Christer