Subject: [Sip] Ongoing Expert Review: Comments on draft-johnston-sip-osp-token-04.txt

From: "Dean Willis" <[email-masked]>
Date: Wed, 23 Apr 2003 15:24:10 -0500

Ok, here are my comments on the P-header for osp-tokens. If anybody else has
something to say, please say it soon.

Draft Section 1, P4 says:
-------
   We propose to use existing IETF protocols and proposals in Internet 
   Drafts for interdomain IP telephony calls with QoS as a first step 
   toward a uniform AAA approach. The approach outlined here may be 
   useful later for developing a uniform AAA architecture and protocols 
   for other application layer services. 
---------

<dean> Don't "propose", document  . . . . Perhaps "This draft documents a
propietary SIP extension header field that may be used to exchange open
settlement protocol [4] information in the context of a SIP session
establishment." </dean> 

Draft, Figure 1 says:
----------------------    
                              Clearinghouse             
             +------+------+     +------+     +------+------+ 
             |Policy|  OSP | OSP | OSP  | OSP | OSP  |Policy| 
             |Server|Client|<--->|Server|<--->|Client|Server| 
             +------+------+     +------+     +------+------+ 
                | |                                   |  | 
    Domain 1    | +-----+                        +----+  |    Domain 2 
                |       |                        |       | 
            +-----+     |                        |    +-----+ 
            | PEP |     |                        |    | PEP | 
 +-----+    +-----+     |                        |    +-----+    +-----+ 
 | SIP |SIP | SIP |     |                        |    | SIP |SIP | SIP | 
 | UAC |<-->|Proxy|-------SIP INVITE with OSP Token-->|Proxy|<-->| UAS | 
 +-----+    +-----+     |                        |    +-----+    +--+--+ 
                        |                        |                  | 
                        |                        |                  | 
   SIP                  |                        |                  | 
  Phone            +------+                  +------+            +--+--+ 
 +------+          | Edge |       RSVP       | Edge |            |     | 
 | RSVP |    RSVP  |Router|      tunnel      |Router|     RSVP   | MG  | 
 | Host |<-------->|      |<---------------->|      |<---------->|     | 
 +------+          +------+   Transit Nets   +------+            +-----+ 

                  Figure 1:   Model for interdomain QoS phone call 
------------------

<dean> What the heck is an "RSVP tunnel"? Is this something like a GRE
tunnel between two edge routers which run RSVP such that it doesn't require
RSVP support in the routers traversed by that tunnel? Is this usage
documented somewhere, and if so, can you please give a reference in the
references section? Speaking of which, do we need to informatively reference
RSVP in this spec?</dean>

Draft, Section 3, Para 3 says:
------------------------------
   For these reasons, a new SIP header is proposed instead of a new MIME 
   type for OSP authorization tokens. 
------------------------------
<dean>  s/header/header field/ -- repeat in several places throughout doc
</dean>

Draft, Section 4, P 3 says:
---------------------------
   which the header filed can be used
---------------------------
<dean> s/filed/field/ </dean>

Draft, Section 5 says:
----------------------
5.   Protocol Semantics 
    
   The OSP Token is always encoded per base64 and only allowed in INVITE 
   requests and 200 OK responses to INVITEs. 
----------------------

<dean> Is there any implication for early media?  Oh no, I said Early Media!
Make the Pain Stop!</dean>

Draft Section 5.1 says:
-----------------------
5.1    User Agents 
    
   A UAC MAY include the header an INVITE requesting QoS using AAA. 
-----------------------
<dean> s/header/header field/ </dean>

Draft, Section 6 says:
----------------------
6.   Example Message 
    
   This SIP INVITE message is an example exchange between the two 
   domains as shown in Figure 1: 
    
   INVITE sips:[email-masked];user=phone SIP/2.0 
   Via: SIP/2.0/TLS proxy.domain1.com:5061;branch=z9hG4bK3a56d3.1 
   Via: SIP/2.0/TLS phone1.domain1.com:5061;branch=z9hG4bK3a5654 
    ;received=192.0.2.1 
   Max-Forward: 69 
   From: Alice <sips:[email-masked]>;tag=3 
   To: <sips:[email-masked];user=phone> 
   Call-ID: [email-masked] 
   CSeq: 1 INVITE 
   Contact: <sips:[email-masked]> 
   Record-Route: <sips:proxy.domain1.com;lr> 
   P-OSP-Auth-Token: "YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t 
   HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH 
   6ghyHhHUujpfyF47GhIGfHfYT64VQbnj" 
   Content-Type: application/sdp 
   Content-Length: 184 
    
   v=0 
   o=alice 9735285123 9721273312 IN IP4 phone1.domain1.com 
   s=-   
   c=IN IP4 phone1.domain1.com    
   t=0 0 
   m=audio 9876 RTP/AVP 0  
   a=rtpmap: 0 PCMU/8000  
------------------------------

<dean? The domain usage should align with RFC26206, aka "example.com"
</dean>

The draft's IANA considerations section says:
---------------------------------------------
IANA Considerations 
    
   Registration of "P-OSP-Auth-Token" SIP header field 
    
   This document defines a new private SIP header field, "P-OSP-Auth-
   Token".  As recommended by the policy of the Transport Area [3], this 
   header should be registered by the IANA in the SIP header registry, 
   using the RFC number of this document as its reference. 
    
    Name of Header:          P-OSP-Auth-Token 
    
    Short form:              None 
    
    Registrant:              Alan Johnston

                             [email-masked] 
    
    Normative description:   This document 
---------------------------------------------

<dean> The reference given, [3], is a reference to Cryptographic Message
Syntax. I think this is not what you want to point to. You probably need a
reference to RFC3427, the SIP Change Process, which augments the RFC361 IANA
process to account for P-headers.  Editorially, it would be nice to see the
IANA Considerations section numbered and listed in the ToC.</dean>

The draft's security considerations section says:
-------------------------------------------------
Security Considerations 
    
   The security and handling of OSP tokens is covered in [4] which 
   includes encryption and the use of IPSec.  
    
   The P-OSP-Auth-Token header field may be protected using standard SIP 
   mechanisms such as TLS transport and/or S/MIME encryption as detailed 
   in [1]. 
--------------------------------------------------

<dean> This is, well, a little light. It would be nice to see some
discussion of exactly how the threat model in [4] is exposed by carrying OSP
in SIP, and have a little more discussion of how the referenced security
mechanisms protect from those exposures. </dean>

--
Dean

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

---

From: Alan Johnston <[email-masked]>
Date: Mon, 28 Apr 2003 09:24:45 -0500

Dean,

Thanks for your comments - I'll make the changes suggested.  I'll 
investigate the RSVP issue you mention.

Thanks,
Alan Johnston
MCI