headers
Thomson, Martin | 1 Nov 2005 05:26

Comments: draft-rosenberg-simple-common-policy-caps-02

I've cross-posted this because there are folks in GEOPRIV who are interested.

Comments for: An Extensible Markup Language (XML) Representation for
Expressing Presence Policy Capabilities
(draft-rosenberg-simple-common-policy-caps-02.txt)

-- General

(Summary: The draft describes a means of conveying information about the level
of support for common-policy features.  This information is carried within
the body of a policy document and is represented by XML elements.  Each
feature is represented by an element, and the presence of this element
indicates support for that feature.)

This draft is essential if common-policy is to have any longevity.  As
stated, the basic set of features provided by common-policy are limited - the
idea being that it is extended by other specifications or vendor extensions.
If this sort of mixed content is allowed, it is very useful to have some
means of communicating capabilities.

-- Mode of operation

(Summary: A client may query the capabilities of a server by requesting a
document before publishing any content.)

As far as this usage is concerned, I don't anticipate any problems.  Each
protocol needs to have a means of requesting this document.

I would be a little stricter with regards to specifying how a client retrieve
the document though.  Suggest that you RECOMMEND that servers don't remove
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 11 Nov 2005 19:25

Domain identifier in common policy

The last remaining open issue in common policy is the format of the 
domain attribute in common policy.

Concrete suggestion:

Use RFC 3987 (internationalized domain names):

ihost = IP-literal / IPv4address / ireg-name

Every URI is also an IRI, so this should work generally. This supports 
both IPv4 and IPv6. RFC 3987 also provides comparison rules, in Section 
5. This has the advantage that the same code would already be needed for 
the full IRI comparison for the 'id' parameter.

Henning
Permalink | Reply | 44 comments |
headers
Andrew Newton | 14 Nov 2005 20:54
Picon

Re: [Geopriv] Domain identifier in common policy


On Nov 11, 2005, at 1:25 PM, Henning Schulzrinne wrote:

> The last remaining open issue in common policy is the format of the  
> domain attribute in common policy.
>
> Concrete suggestion:
>
> Use RFC 3987 (internationalized domain names):
>
> ihost = IP-literal / IPv4address / ireg-name
>
> Every URI is also an IRI, so this should work generally. This  
> supports both IPv4 and IPv6. RFC 3987 also provides comparison  
> rules, in Section 5. This has the advantage that the same code  
> would already be needed for the full IRI comparison for the 'id'  
> parameter.

Given Jonathan's comment, I thought he was more focused on actual  
domain names and not IP addresses.  I don't care.  I just thought  
that was what was said.

Even if the domain field is limited to ireg-name, I do not believe  
that solves the problem.  I'm not an IRI expert, but it appears that  
not all ireg-name values are legal domain names.

And I still wonder about the IDN case, especially given that this  
appears to be an exact match.  Which form is the exact match  
performed on, the UTF8, a NamePrepped domain, or an ACE encoded  
domain.  Given that there can be variants of an IDN floating around
(Continue reading)

Permalink | Reply | 42 comments |
headers
Henning Schulzrinne | 14 Nov 2005 21:17

Re: [Geopriv] Domain identifier in common policy

> Given Jonathan's comment, I thought he was more focused on actual  
> domain names and not IP addresses.  I don't care.  I just thought  that 
> was what was said.

Right; I just want to make sure we don't get into an IPv4 vs. IPv6 
discussion.

> 
> Even if the domain field is limited to ireg-name, I do not believe  that 
> solves the problem.  I'm not an IRI expert, but it appears that  not all 
> ireg-name values are legal domain names.

Sure, but this is not a new problem. example.andy, ccs.columbia.edu or 
ex$ample.com are not valid domain names, either, even without the I18N 
problems. Thus, there will always be valid domain-looking strings that 
don't match any protocol-possible string. This isn't an issue - the rule 
  component just will never match and somebody will have to fix the typo.

> 
> And I still wonder about the IDN case, especially given that this  
> appears to be an exact match.  Which form is the exact match  performed 
> on, the UTF8, a NamePrepped domain, or an ACE encoded  domain.  Given 
> that there can be variants of an IDN floating around  on the wire, it 
> always seems to me that the comparison should be done  on the ACE version.

I may be looking at the wrong thing, but Section 5 of RFC 3987 seems 
relevant:

  5.  Normalization and Comparison . . . . . . . . . . . . . . . . . 21
        5.1.  Equivalence  . . . . . . . . . . . . . . . . . . . . . . 22
(Continue reading)

Permalink | Reply | 39 comments |
headers
Andrew Newton | 14 Nov 2005 22:04
Picon

Re: [Geopriv] Domain identifier in common policy


On Nov 14, 2005, at 3:17 PM, Henning Schulzrinne wrote:
>> Even if the domain field is limited to ireg-name, I do not  
>> believe  that solves the problem.  I'm not an IRI expert, but it  
>> appears that  not all ireg-name values are legal domain names.
>
> Sure, but this is not a new problem. example.andy, ccs.columbia.edu  
> or ex$ample.com are not valid domain names, either, even without  
> the I18N problems. Thus, there will always be valid domain-looking  
> strings that don't match any protocol-possible string. This isn't  
> an issue - the rule  component just will never match and somebody  
> will have to fix the typo.

I guess what I'm trying to say is that not all IRIs produce a valid  
domain name.  If you are saying, "it doesn't matter, these are never  
handed to gethostbyname()" then I agree with you.

>> And I still wonder about the IDN case, especially given that this   
>> appears to be an exact match.  Which form is the exact match   
>> performed on, the UTF8, a NamePrepped domain, or an ACE encoded   
>> domain.  Given that there can be variants of an IDN floating  
>> around  on the wire, it always seems to me that the comparison  
>> should be done  on the ACE version.
>
> I may be looking at the wrong thing, but Section 5 of RFC 3987  
> seems relevant:
>
>  5.  Normalization and Comparison . . . . . . . . . . . . . . . . . 21
>        5.1.   
> Equivalence  . . . . . . . . . . . . . . . . . . . . . . 22
(Continue reading)

Permalink | Reply | 37 comments |
headers
Henning Schulzrinne | 14 Nov 2005 22:34

Re: [Geopriv] Domain identifier in common policy

I'm probably well beyond my I18N/IDN depth here, so I agree that 
external advice is called for.

My understanding of RFC 3987, Section 5, is that these steps are 
performed in sequence, starting with the low-cost step in 5.3.1 and 
progressing to steps requiring more work if there's no match.

First, I think we can restrict ourselves to discussing URIs appearing in 
specific protocols, such as part of a SIP From URI or an XMPP URI.

There are probably two cases: Protocols that are clearly specified as 
using IRIs already (XMPP, say) and those that require discussion (SIP, 
say). [Discussion is required for SIP since SIP itself allows UTF-8 and 
RFC 3987 Section 6.3 alludes to the fact that most schemes do not have 
to be upgraded to support IRIs.]

I'll stick to the IRI case. If the IRI shows up in the protocol request, 
the steps in 5.3.1 would be executed until either a match occurred or 
the process falls off the ladder mentioned in the spec. Clearly, some of 
the comparison steps do not apply since they concern the port number or 
path components of the comparison.

 From my reading of 3987, the punycode version would be compared as well 
during the ladder, presumably by converting the IDN to punycode. (I 
suspect that the conversion from UTF-8 to punycode is unique, while I 
suspect that this is not true in the other direction. In other words, 
multiple UTF-8 strings could generate the same punycode.)

This is all a bit messier than ASCII comparison, but I don't think we 
want users to edit punycode into their XML rule files.
(Continue reading)

Permalink | Reply | 35 comments |
headers
Bernie Volz (volz | 14 Nov 2005 22:44
Picon
Favicon

RE: Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

Having looked over this draft, I object to the language (MUST NOT) that
prohibits the client from sending this option (with data) to the server.

While I understand that there are security implications of doing so,
pointing out those security issues (such as referencing RFC 3694,
"Threat Analysis of the Geopriv Protocol") and encouraging use only on
secured networks or under special circumstances makes much more sense
than a blanket MUST NOT.

There are two core security threats in allowing this information to be
sent from client to server:
1) Leakage of location information to other devices on the network
2) Alternation or faking of location information to the server

For (1), many of the devices could obtain this information in the
response from the server. Admittedly it is a bit easier to capture the
client's transmission (as it is broadcast in IP4 or multicast in IPv6).
But, the difference here is fairly minor in most networks.

There are networks that are secured (perhaps physically) and there are
also times when sending this information to a server is extremely
desirable and not a security threat, such as during build-out of the
cable plant.

For (2), this depends on if and how the server uses the received
information. And, that is up to the administrative policies on the
server.

For example, a server might allow a client to communicate one of <n>
possible locations at which it may be located or allow a client to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henning Schulzrinne | 14 Nov 2005 22:55

Re: Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

Thanks for your comments. I thought this issue had been resolved, but 
let me try to introduce a compromise position. One of the issues raised 
in the past is that the location information does not have a privacy 
section (unlike PIDF-LO). However, this can be resolved by declaring a 
default "do not distribute" policy for this application.

[I personally don't have a strong opinion on this subject and just want 
to get this draft done, after almost three years.]

Henning

Bernie Volz (volz) wrote:
> Having looked over this draft, I object to the language (MUST NOT) that
> prohibits the client from sending this option (with data) to the server.
> 
> While I understand that there are security implications of doing so,
> pointing out those security issues (such as referencing RFC 3694,
> "Threat Analysis of the Geopriv Protocol") and encouraging use only on
> secured networks or under special circumstances makes much more sense
> than a blanket MUST NOT.
> 
> There are two core security threats in allowing this information to be
> sent from client to server:
> 1) Leakage of location information to other devices on the network
> 2) Alternation or faking of location information to the server
> 
> For (1), many of the devices could obtain this information in the
> response from the server. Admittedly it is a bit easier to capture the
> client's transmission (as it is broadcast in IP4 or multicast in IPv6).
> But, the difference here is fairly minor in most networks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernie Volz (volz | 14 Nov 2005 23:20
Picon
Favicon

RE: Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

Henning:

I assume this default "do not distribute" policy applies for either
direction (client to server (server should not distribute) and server to
client (client should not distribute)) or do you propose to have this
apply only when the client sends it to the server?

If this policy doesn't apply when from server to client (what the I-D
currently allows), what policy does apply to the information the client
receives as this privacy information isn't communicated? And, thus isn't
this be a flaw in the current document that should be addressed
(irrespective of the issue I raised below).

- Bernie

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs <at> cs.columbia.edu] 
> Sent: Monday, November 14, 2005 4:55 PM
> To: Bernie Volz (volz)
> Cc: Ralph Droms (rdroms); DHCP discussion list; Ted Hardie; 
> geopriv <at> ietf.org
> Subject: Re: [dhcwg] Re: I-D 
> ACTION:draft-ietf-geopriv-dhcp-civil-07.txt
> 
> Thanks for your comments. I thought this issue had been resolved, but 
> let me try to introduce a compromise position. One of the 
> issues raised 
> in the past is that the location information does not have a privacy 
> section (unlike PIDF-LO). However, this can be resolved by 
> declaring a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Newton | 14 Nov 2005 23:30
Picon

Re: [Geopriv] Domain identifier in common policy


On Nov 14, 2005, at 4:34 PM, Henning Schulzrinne wrote:

> I'm probably well beyond my I18N/IDN depth here, so I agree that  
> external advice is called for.

Me too.  So no argument here.

> My understanding of RFC 3987, Section 5, is that these steps are  
> performed in sequence, starting with the low-cost step in 5.3.1 and  
> progressing to steps requiring more work if there's no match.

I'm not saying you are wrong, but that's not the impression I got  
when reading that section.  Otherwise, whey is step 1 (simple string  
comparison) a MUST in certain situations if it always a MUST.

> First, I think we can restrict ourselves to discussing URIs  
> appearing in specific protocols, such as part of a SIP From URI or  
> an XMPP URI.

I do not agree with this.  If HELD comes to fruition, we'll be  
talking about HTTP schemes as well.

> There are probably two cases: Protocols that are clearly specified  
> as using IRIs already (XMPP, say) and those that require discussion  
> (SIP, say). [Discussion is required for SIP since SIP itself allows  
> UTF-8 and RFC 3987 Section 6.3 alludes to the fact that most  
> schemes do not have to be upgraded to support IRIs.]
>
> I'll stick to the IRI case. If the IRI shows up in the protocol
(Continue reading)

Permalink | Reply | 33 comments |

Gmane