Subject: RE: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.t xt

From: [email-masked]
Date: Wed, 5 Jun 2002 17:08:16 +0100

Jonathan,

Thanks for your expert comments.  I return a few comments below...

Duncan

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 29 May 2002 22:04
To: [email-masked]
Subject: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.txt

Comments on this draft:

The title needs to have the acronym SIP expanded.

[Duncan]  Yep- it will from now on read, "Private Session Initiation
Protocol Extension for Access Network Information"  [/Duncan]

The abstract reads oddly; it seems like a sentence has been misplaced:

> 1. Abstract 
>    This mechanism is useful in SIP networks that provide layer 2/layer 
>    3 connectivity through different access technologies. SIP User 
>    Agents 
>    This document defines the private SIP extension header P-Access-
>    Network-Info. may use this header to relay information about the 
>    access technology to serving proxies in their home network.

I think "SIP User Agents" needs to be moved before "may use this header"

[Duncan] How did that happen?  ;-)  I've corrected this.  [/Duncan]

The applicability statement is not quite right. It needs to capture the
specific assumptions and scenarios which limit the scope of this draft.
I would propose something like the following:

"This draft is appropriate in environments where SIP services are
dependent on a SIP elements knowing details about the IP and lower layer
technologies used by a UA to connect to the SIP network. Specifically,
the extension requires that the UA know the access technology it is
using, and that a proxy desires such information to provide services.
Generally, SIP is built on the "Everything over IP and IP over
Everything" principle, where the access technology is not relevant for
the operation of SIP. Since SIP systems generally should not care or
even know about the access technology, this draft is not for general SIP
usage. 

The information revealed in the P-Access-Network-Info header is
potentially very sensitive. Proper protection of this information
depends on the existence of specific business and security relationships
amongst the proxies that will see messages containing this header. It
also depends on explicit knowledge of the UA on the existence of those
relationships. Thefefore, this mechanism is only appropriate in
environments where the appropriate relationships are in place, and the
UA has explicit knowledge that they exist."

[Duncan] I'm perfectly happy to use this wording [/Duncan]

> Other examples include a laptop connected to a 
>    wireless LAN at an airport, or a laptop connected to a local ISP 
>    from a hotel room. 

I have to agree with Bob's assessment that the appropriate business
relationships will not be in place between the proxy at the airport and
the proxy in my home network. Therefore, this example is really not
appropriate.

[Duncan] It's deleted. [/Duncan]

> For instance, 
>    the type of access being used may influence home network decisions 
>    on what level of security to apply to sessions. 

I don't see what the access network has to do with session level
security (or what proxies have to do with session level security).

[Duncan] Just that where the access network is a GPRS network provided by
OpCo1 and the 3GPP IMS (SIP) network is also provided by OpCo1, then an
operator may decide that the level of security applied to the application
layer needs to be either lower (GPRS provides security) or higher (If
there's a wireless link involved, let's be more careful.  [/Duncan]

> It may be desired that the home network have the knowledge of some 
>    information relating to the network that provided access to the 
>    service. 

This sentence is awkward, I suggest rewording to "The home network may
desire knowledge about the access network."

[Duncan] Done. [/Duncan]

The introduction and overview aren't really different. I would suggest
moving the overview into the introduction, and have a separate "Overview
of Operations" section which overviews the basic operation of the
extension. That section is fairly short, since the extension is simple.
Something like:

---
Overview of Operation

This section provides an overview of the operation of this extension,
and is not normative in nature.

When a user agent generates a SIP request which it knows is going to be
securely sent to its home network, it inserts a P-Access-Network-Info
header into the request. This header contains information on the access
network that the UA is using to get IP connectivity. The header is
ignored by intermediate proxies between the UA and the home proxy. The
home proxy can inspect the header and make use of the information
contained there to provide services. Before proxying the request
onwards, the home proxy strips the header from the request.
---

[Duncan] Done.  [/Duncan]

> The P-Access-Network-Info header MAY be inserted by a UA. Proxies, 
>    MUST NOT add to or modify the contents of the P-Access-Network-Info. 

This text appears in the section that describes teh syntax and values of
the P-header. Generally (as we learned with bis), its better to place
normative behavior in one place. Therefore, I suggest you move any
normative behavior like this into section 8. Section 7 should remain
nothing more than a description of the syntax of the header and the
meaning of the various parameters.

[Duncan] Done.  [/Duncan]

> The proxy in the home network may act upon any information in the P-
>    Access-Network-Info header if it is present, to provide a different 
>    service  depending on the network through which the UA is accessing 
>    the server. For example, for cellular radio access networks the home 
>    network may use the cell ID to provide basic localised services. 
>     
>    A proxy in the home network MUST delete the header before forwarding 
>    the message outside of its own administrative network domain or 
>    outside a trusted administrative network domain. 

this text belongs in 8.2.

[Duncan] Done.  [/Duncan]

> Some systems may require that the P-Access-Network-Info header is 
>    only sent by the UAC when a secure connection to the proxy in the 
>    home network is present.  For example, in 3GPP systems, the UAC MUST 
>    NOT send this header in the initial unauthenticated REGISTER 
>    request. 

this text belongs in 8.1.

[Duncan] Done.  [/Duncan]

> A UAC supporting this extension may be capable of accessing the 
>    services provided by its home network via one or more access 
>    technologies. 

This sentence sort of states the obvious. Obviously the UAC is capable
of accessing the SIP network through some access technology.

[Duncan] Deleted.  [/Duncan]

> Such a UAC must know the values to use for each type 
>    of supported access technology. The means of this determination are 
>    outside the scope of this document. 

this belongs in section 8.1. 

[Duncan] Done.  [/Duncan]

> The home network must know the possible values that a particular UA 
>    may use to populate the access-type and access-info fields. 
>     
>    In other words, a home network with business agreements allowing 
>    users to access via a particular technology must be able to parse 
>    the P-Access-Network-Info header containing an access-type for that 
>    technology in order to use this information. 
>     
>    For example, the access-type could read "IEEE-802.11b".  If a home 
>    network knows it has a business agreement with a W-LAN access 
>    network, it must be ready to understand the value "IEEE-802.11b". 
>    Similarly, a UAC supporting this extension that can access via W-LAN 
>    must be able to insert the relevant value. 

This text confuses me, since it tries to belabor an obvious point - that
the proxy must know how to parse these values. Maybe I am missing
something. Perhaps this is related to the fact that no definition is
provided for 3gpp-cgi and 3gpp-utran-cell-id? I don't see why you can't
just provide a definition for those and then delete the statements
above.

[Duncan] The definition for the cell-id is just that it is a string of hex.
It is defined already in 3GPP specifications.  I agree the current text in
my draft is probably not adding much.  I can't reference 3GPP specifications
though, right?  I wanted to describe it in this draft, as "You can put
anything you want in here as a 'string'."  "3GPP mobiles will be limited by
3GPP specifications as to what they can put in there." [/Duncan]

> A UAC that supports this extension and is willing to disclose the 
>    related parameters MAY insert the P-Access-Network-Info header in 
>    any SIP message request. 

You probably need to provide some guidance on when it ought to be doing
that. I have a suspicion that you do have specific requirements (like,
every request in order to keep cell-id up to date).

[Duncan] Agreed.  [/Duncan]

> This document does not define either the nature of the information 
>    or the messages where the P-Access-Network-Info needs to be 
>    inserted. 

This is confusing; it does define the nature of the information. What am
I missing?

[Duncan] OK, bad wording again.  What I mean is that this document only
provides *some* values to put in the 'access-type' and 'access-info' fields.
There's the chance for other people to define their own tokens etc.  The
nature of the information is not meant to be restricted to providing the
cell ID (that's how 3GPP may use this extension, yes, but another system may
want to say 'Airport Lounge' in the access-info field).  That's waht I meant
to say, but I agree, I need to re-word it.  [/Duncan]

> A proxy, typically located in the home network, and therefore 
>    trusted, MUST delete the header when the SIP signaling is forwarded  
>    to a SIP server located in a non-trusted administrative network 
>    domain. The access network information is used by a home network and 
>    is of no interest to the destination 
>    network. 

What about a trusted administrative network domain? I think that the
home proxy MUST strip this in all cases.

[Duncan]  Well, a home proxy may wish to leave the header in and forward the
message to an Application Server.  As long as this is all in the home
trusted domain, then it's okay?  [/Duncan]

>  This extension assumes that the access network is trusted by the UA 
>    (because the UAÆs home network has a trust relationship with the 
>    access network), as described in section 7. 

The trust relationship is not between the access network and the home
network. The assumption is that there is a trust relationship between
the UA and the proxy it sends the request to, and then between all
proxies between the outbound proxy and the home proxy.

[Duncan]  OK.  [/Duncan]

>  The home network uses the information contained in this header to 
>    provide additional services  and 

This sentence ends mid-stream.  [Duncan]  Ooops.  [/Duncan]

>  UAs are expected to provide correct information.  However, there are 
>    no security problems resulting from a UAC inserting incorrect 
>    information. 

Well, I doubt that is true in the case of cell-id. Providing false
location information can be used for all sorts of bad things.

[Duncan]  A rogue user or rogue implementation putting false cell-ID
information in this header means that the user doesn't get the correct
address for the nearest Pizza Restaurant, or doesn't get to their voicemail
from abroad.  It would be a nasty fault, but is it really that much of a
security problem?  [/Duncan]

Thanks,
Jonathan R.

[email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
>         Title           : The SIP Access Network Info header
>         Author(s)       : D. Mills
>         Filename        : draft-mills-sip-access-network-info-02.txt
>         Pages           : 8
>         Date            : 28-May-02
> 
> This mechanism is useful in SIP networks that provide layer 2/layer
> 3 connectivity through different access technologies. SIP User
> Agents
> This document defines the private SIP extension header P-Access-
> Network-Info. may use this header to relay information about the
> access technology to serving proxies in their home network. The
> serving proxy may then use this information to optimize services for
> the UA. For example, a 3GPP terminal uses this header to pass
> information about the access network such as radio access technology
> and cell ID to its home service.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-
> 02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
> message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-mills-sip-access-network-info-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE
> /internet-drafts/draft-mills-sip-access-network-info-02.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ------------------------------------------------------------------------
> 
> Subject:
> Date: Wed, 29 May 2002 10:32:52 -0400
> 
>   ------------------------------------------------------------------------
> 
>    ATT38948.txtName: ATT38948.txt
>                Type: Plain Text (text/plain)
> 
>                 Access-Type: anon-ftp
>  Document Info:        Site: internet-drafts
>                        Mode: ftp.ietf.org

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jun 2002 17:30:20 -0400

> there's a wireless link involved, let's be more careful.  [/Duncan]

Just because GPRS provides security doesn't say anything about sip 
security. Lets be careful here.

>>   Similarly, a UAC supporting this extension that can access via
> 
> W-LAN 
> 

I don't see why you don't define the values in this spec... shouldn't 
these specs at least stand alone and work outside of 3gpp so long as the 
applicability statement holds true?

> to say, but I agree, I need to re-word it.  [/Duncan]

If you want to define some baseline values, but allow others to register 
  or use additional values, then you should say that.

>>   domain. The access network information is used by a home network
> 
> and 
> 

It gets back to the privacy issue. THe caller may not wish for other 
domains to know my location. You don't have a way to express privacy 
preferences, so you have to strip it when sending to any other 
administrative domain. App servers within the same home domain are ok i 
guess.

> security problem?  [/Duncan]

The 911 operators might not like it.

Thanks,
Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 10 Jun 2002 09:11:13 -0500

> > [Duncan] The definition for the cell-id is just that it is a string
of
> > hex.
> > It is defined already in 3GPP specifications.  I agree the current
text
> > in
> > anything you want in here as a 'string'."  "3GPP mobiles will be
limited
> > by

Here's the rub -- the actual format is both defined in 3GPP and subject
to change in 3GPP. This gives us a change control problem if we attempt
to define it here.

It IS possible to use external references to published specifications in
an IETF document.

From RFC 2026 (this stuff is in Section 7)

   An Internet Standard TS or AS may incorporate an open external
   standard by reference.  For example, many Internet Standards
   incorporate by reference the ANSI standard character set "ASCII" [2].
   Whenever possible, the referenced specification shall be available
   online.

On the other hand, I'm not yet certain whether the 3GPP rel 5 work is
considered "referenceable". I'm sure it will be eventually, but is it
now? Duncan, what is the state of the document defining cell-id?

--
Dean