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

From: [email-masked]
Date: Mon, 10 Jun 2002 11:26:57 +0100

Jonathan,

With regards to the following issue:

[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]

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?

I don't understand your point.  I think this draft does stand alone, in that
it gives you the SIP header definition and the fields that go in that
header, and then it tells you that the content of some of the fields is a
string of text.  If some standards body X want to use the 'cgi-3gpp' filed
and put some random parameter (like screen size) in there, then I guess they
can, as long as it is clearly specified in their own specs?

The coding, for example, of a GERAN Cell ID, is specified within 3GPP, and
has been for some time.  The P-Access-Network-Info header is designed to
carry ANYTHING related to the access network.  Currently, my draft defines
two specific chunks of information (merely to break the information down
into sensible bits of information, rather than just saying 'Cell-ID' (yes,
the draft is intended to satisfy a 3gpp requirement, but if possible I
wanted it to be (potentially) useable by others):

1. Access-type; and
2. Access-info.

Access-type was designed to contain ANYTHING.  That was the idea.  However,
some obvious values for the access-type filed have been specified in this
draft.  There is the possibility to add further values.

Access-info was intended to be able to contain ANYTHING.  3GPP has the
specific requirement to carry, for instance, a CGI ("cgi-3gpp=01 FF 00 FF FF
FF FF" ).  I don't want to define how you code the stuff after the '='
because this is defined in 3GPP.

All I want to do is say that any system using a 3GPP radio access network
might want to send the cell ID, in which case they shall use this parameter,
and everything to the right of the '=' is just text that the receiver will
understand based on 3GPP specs.

I thought I'd done this?  I thought 'Quoted-string' was enough.  It's
difficult, when I  can't reference the 3GPP specification.

Best Regards,

Duncan

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 06 June 2002 22:30
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Re: I-D
ACTION:draft-mills-sip-access-network-info-02.t xt

[email-masked] wrote:
> Jonathan,

>>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]

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

>>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]

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?

>>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]

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

> 
> 
> 
>>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]

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.

>> 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]

The 911 operators might not like it.

Thanks,
Jonathan R.

-- 
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: [email-masked]
Date: Mon, 10 Jun 2002 15:29:39 +0100

Dean,

As far as I'm aware, a CR against 3GPP TS24.229 to add text on the
P-Access-Network-Info header was approved at the CN plenary meeting last
week.  That text refers to 'draft-mills-sip-access-network-info' for the
syntax of the header and then explicitly defines some additional coding
rules (e.g. that if the access-type = "3GPP-GERAN" then the access-info
shall contain the cell ID, coded as follows.....)  This is the bit that can
only be specified ONCE in 3GPP specs.

Admittedly, 3GPP TS24.229 may need revising slightly in the future, to
reflect a minor change in the syntax of the header in the latest version of
the draft (e.g. '3gpp-cgi' becomes 'cgi-3gpp'), but then it'll need revising
slightly to update the reference from an I-D to an RFC as well (hopefully!)

So this now seems to suggest that I can put a reference towards the
'additional coding rules' in 24.229 in my p-header draft?

Best Regards,

Duncan

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 10 June 2002 15:11
To: Jonathan Rosenberg; [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Re: I-D

> applicability statement holds true?

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

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 12 Jun 2002 14:59:24 +0100

Judging by the RFC text quoted below, 3GPP TS 24.229 is referencable, and has been since March. The version containing the relevant text will be available in a couple of weeks time - the content is approved.

Keith

> > > [Duncan] The definition for the cell-id is just that it 
> is a string
> of
> > > hex.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jun 2002 17:24:35 -0400

Bob,

I don't make the policy. I just follow it. See:

http://www.rfc-editor.org/policy.html

which seems pretty clear to me.

-Jonathan R.

Bob Penfield wrote:
> ----- Original Message -----
> From: "Jonathan Rosenberg" <[email-masked]>
> 
>>The title needs to have the acronym SIP expanded.
> 
> 
> I know this is a really minor point, but why does SIP need to be
> expanded in
> the title? Most other I-Ds and RFCs (besides the base spec of course)
> use
> the acronym of the protocol in their title. The problem we've had in the
> past is that the title did not even include the acronym. Why not require
> the
> expansion in the abstract?
> 
> cheers,
> (-:bob