Subject: Re: Last Call: draft-ietf-v6ops-natpt-to-historic (Reasons to Move NAT-PT to Historic Status) to Informational RFC

From: Eliot Lear <[email-masked]>
Date: Thu, 01 Mar 2007 09:42:05 +0100

Sam,
> I disagree with this characterization of the document.  I think it is
> more like we have existing NAT mechanisms; we have strategies for
> making them work.  Dual stack nodes is a better way forward than
> creating a new NAT mechanism to move from IPV6 to IPV4 and trying to
> make that (with a different set of problems than traditional NAT)
> work.
>
> I don't think this document is anti-NAT.  Can you help me understand
> why I'm wrong or reconsider how much of your argument still applies?
>
>   

While I agree that use of NAT-PT for transition is probably not the best 
way forward, the overall NAT question hangs in the air when we deprecate 
this document.  With IPv4 the impetus for NAT was a combination of 
address exhaustion concerns and routing issues.  In the case of IPv6 the 
issues are far more operational in nature, and depend very much on a 
combination of RIR policies regarding PI addressing (currently in vogue) 
and an end network's need for ease of administration through a 
renumbering event.  We can only address *some* of those problems, and 
the ones that remain may well encourage NAT.

So, for those who hate NAT, please consider the problem of enterprise 
administrators who face this decision.  For example, improved 
programmatic linkage between service providers and the end nodes for 
secure allocation of networks.  While prefix delegation is defined in 
DHCP, the linkage back to DNS is shaky at best, since both forward and 
reverse zone updates are required.  See RFC 4192 for more on this.

Barring satisfactory resolution, enterprises and vendors will take the 
path of least resistance (again).

Eliot

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Mar 2007 10:11:11 +0100

On 2007-02-28 17:02, Hallam-Baker, Phillip wrote:
> The core assumption here seems to be that NAT is a bad thing so lets get rid of NAT rather than trying to make NAT work.

This is startlingly irrelevant to the present document. We have a large corpus
of documents about the issues caused by NAT and about partial solutions. But
this document is about NAT-PT, which is something else.

> The questions that I would like to see answered that I don't see in the document are
> 
> 1) What is the deployment strategy for IPv6 without NAT?

As Fred has pointed out, there is also a large corpus of documents
about this, and it's clearly out of scope for the present document.

> 2) Are people actually using or deploying NAT-PT?

Had you read the draft carefully, you would know that
   "From a deployment perspective, 3GPP
    networks are currently the only 'standardised' scenario where an
    IPv6-only host communicates with an IPv4-only host using NAT-PT as
    described in the 3GPP IPv6 transition analysis [RFC4215], but NAT-PT
    has seen some limited usage for other purposes."

> 3) Exactly why should an application be invited to care about this issue?

Others have responded on this, but to summarise: an application that
assumes addresses have end to end validity will fail. That much, NAT-PT
has in common with NAT.

     Brian

---

From: [email-masked]
Date: Thu, 01 Mar 2007 03:39:21 -0700

Fred Baker writes: 

On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote: 

> The core assumption here seems to be that NAT is a bad thing so  lets get 
> rid of NAT rather than trying to make NAT work.
> ...

Actually this has already been done, please see draft-ietf-v6ops-nap-06.txt 
which has been approved as an informational RFC (currently in the RFC 
editor's hands) for explanations as to why there is no NAT in IPv6. All we 
have is NAT-PT which is supposed to be an interconnection between IPv4 and 
IPv6 networks. And as the draft-ietf-v6ops-natpt-to-historic is proposing to 
do away with this last incident of the NAT abbreviation, even may be going 
away. 

The basic requirement for true end-to-end connectivity makes NAT in any form 
worth reconsidering.

---

From: [email-masked]
Date: Thu, 01 Mar 2007 03:39:21 -0700

Fred Baker writes:

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Mar 2007 08:07:17 -0800

On a thread now unrelated to the topic of NATs,

At 9:42 AM +0100 3/1/07, Eliot Lear wrote:
>With IPv4 the impetus for NAT was a combination of address 
>exhaustion concerns and routing issues.

It is far deeper than that for many IT departments and network users. 
NATs are seen as an easy-to-administer firewall that prevents outside 
people from getting at hosts behind the NAT. To many of us, that is a 
bug because it prevents session initiation from the outside; to many 
users, it is a feature.

Nearly ever home *and SOHO* router today comes with NAT turned on by 
default, and the setting to turn it off is difficult to find. In our 
VPN testing, we have found that some of those routers have bugs that 
prevent the NAT from being turned off. When we report this to the 
vendors (because our tests do not use NATs), we are often literally 
the first people to have noticed this. That's how ingrained NATs are 
to the mentality of users.

State a different way: given the way that some popular operating 
systems are configured out of the box to respond insecurely to 
outsiders, it may be a good thing that NATs are on by default. Of 
course, it would be better if the routers were firewalls with a 
default "all incoming blocked" rule instead of a NAT, but that is not 
how the world works, mostly due to the two issues Eliot brings up 
above. But even if those two issues were magically resolved today, it 
will take us years or decades to convince users that they don't want 
the NATs they have now, and that they instead want to become firewall 
administrators.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eliot Lear <[email-masked]>
Date: Thu, 01 Mar 2007 17:52:45 +0100

Paul,

Without going down the NAThole my real intent here is simply to motivate 
people who think they're bad to please look at the management 
complexities of renumbering.  I know I am looking.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Thu, 01 Mar 2007 12:57:58 -0500

--On Thursday, 01 March, 2007 08:07 -0800 Paul Hoffman
<[email-masked]> wrote:

> It is far deeper than that for many IT departments and network
> users. NATs are seen as an easy-to-administer firewall that
> prevents outside people from getting at hosts behind the NAT.
> To many of us, that is a bug because it prevents session
> initiation from the outside; to many users, it is a feature.
> 
> Nearly ever home *and SOHO* router today comes with NAT turned
> on by default, and the setting to turn it off is difficult to
> find. In our VPN testing, we have found that some of those
> routers have bugs that prevent the NAT from being turned off.
> When we report this to the vendors (because our tests do not
> use NATs), we are often literally the first people to have
> noticed this. That's how ingrained NATs are to the mentality
> of users.

It is even worse than this, for two reasons, discussed below
(since it is now 2007, it is time for me to delivery my annual
whine on the subject).

> State a different way: given the way that some popular
> operating systems are configured out of the box to respond
> insecurely to outsiders, it may be a good thing that NATs are
> on by default. Of course, it would be better if the routers
> were firewalls with a default "all incoming blocked" rule
> instead of a NAT, but that is not how the world works, mostly
> due to the two issues Eliot brings up above. But even if those
> two issues were magically resolved today, it will take us
> years or decades to convince users that they don't want the
> NATs they have now, and that they instead want to become
> firewall administrators.

Yes.

(1) Many of the most powerful consumer, end-user, SOHO, and
small enterprise router-firewalls don't permit the NATs to be
turned off at all, even when multiple public addresses are
available.  Instead, they provide a one-one NAT capability,
either because they are convinced it is safer or because they
are trying to support some sort of "backup network" or "DMZ"
capability and don't have adequate support for the routing
needed to do either with long-prefix public address ranges.

(2) NATs provide a huge advantage for customer support
organizations of ISPs supporting such lower-end (in terms of
financial returns, at least) connections.  With a standardized
NAT setup, the setups of all of their customers are pretty much
the same, including the address ranges used by default.  This
permits much easier (and cheaper) user support than trying to
debug LAN-specific routing tables, arrangements to support both
a LAN and the router providing the the interface between that
LAN and the WAN in a very small address range, and so on.

I continue to believe that, until and unless we come up with
models that can satisfy the underlying problems that NATs
address in the above two cases and implementations of those
models in mass-market hardware, NATs are here to stay, even if
we manage to move to IPv6 for other reasons.  And, conversely,
the perceived difficulties with NATs will be sufficiently
overcome by the above issues to prevent those difficulties from
being a major motivator for IPv6, at least for most of the
fraction of the ISP customer base who cannot qualify for PI
space.

      john

---

From: Douglas Otis <[email-masked]>
Date: Thu, 1 Mar 2007 17:35:50 -0800

On Mar 1, 2007, at 9:57 AM, John C Klensin wrote:

> I continue to believe that, until and unless we come up with models  
> that can satisfy the underlying problems that NATs address in the  
> above two cases and implementations of those models in mass-market  
> hardware, NATs are here to stay, even if we manage to move to IPv6  
> for other reasons.  And, conversely, the perceived difficulties  
> with NATs will be sufficiently overcome by the above issues to  
> prevent those difficulties from being a major motivator for IPv6,  
> at least for most of the fraction of the ISP customer base who  
> cannot qualify for PI space.

One of the "features" contained within Microsoft Vista is a stack  
terminating an IPv6 address encapsulated using RFC4380 Teredo (IPv6  
over IPv4 UDP).  This also works in conjunction with their new name  
resolution protocol offering address structures for navigating  
through Teredo compliant NATs and firewalls.

While this may require rather heavily lifting track the UDP traffic,  
this constrains the growth of router tables and helps retain the  
viability of IPv4 addressing.  At the same time, offers a transition  
into the IPv6 address space which moves a bit closer to the end-to- 
end ideals by leveraging compliant NATs and Firewalls.  Whether  
Teredo proves secure or PRNP functions well, the PNRP name resolution  
service represents a proprietary solution that appears to be without  
IETF IPR statements.  Is this good or bad?  It is concerning.

-Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Mar 2007 11:38:01 +0100

On 2007-03-01 18:57, John C Klensin wrote:
...
> fraction of the ISP customer base who cannot qualify for PI

This is of course one of the major motivations for
draft-ietf-v6ops-nap-06.txt, which is now in the RFC
Editor's queue. While it doesn't tell SOHO gateway
vendors exactly what to do, it does I think make it clear
that there is a secure mass market IPv6 way forward that
has no need for NAT.

     Brian

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 1 Mar 2007 15:37:58 +0100

Hi Bernard,

I received your review. I need more time to process given its length.
In fact the length of your review surprised me a bit given the long (>16 months) discussion we already had about the document.

Ciao
Hannes
 
> -----Ursprüngliche Nachricht-----
> Von: Bernard Aboba [mailto:[email-masked]] 
> Gesendet: Donnerstag, 1. März 2007 06:45
> An: [email-masked]
> Betreff: Re: Last Call: draft-ietf-geopriv-radius-lo 
> (Carrying LocationObjects in RADIUS
> 
> This is a repost of 2 messages previously sent to the 
> [email-masked] list 
> which did not make it to the list.  They are being re-sent 
> here at the 
> request of the RAI ADs.
> 
> ========================================
> To: [email-masked]
> Subject: Re: Last Call: draft-ietf-geopriv-radius-lo 
> (Carrying Location 
> Objects in RADIUS
> From: "Bernard Aboba" <[email-masked]>
> Date: Sat, 17 Feb 2007 16:13:44 -0800
> Cc: [email-masked], [email-masked]
> 
> Review of draft-ietf-geopriv-radius-lo-10.txt
> 
> Overview comments:
> 
> Overall, this document includes many normative statements relating
> to privacy in a number of sections.   As it stands, this makes it very
> difficult to understand exactly what privacy support will be provided
> in various scenarios.   I would strongly urge that these statements
> be consolidated into a single section.
> 
> In terms of RADIUS protocol usage, there are a few problems
> (violation of a MUST NOT provision in RFC 3576, use of non-standard
> RADIUS data types, inappropriate use of complex attributes)
> 
> There are also a lot of editorial issues that need to be cleaned up.
> 
> Given everything, this  document requires substantial  work before
> it would be suitable for publication as an RFC.
> 
> Section 1
> 
>   Wireless LAN (WLAN) access networks are being deployed in public
>   places such as airports, hotels, shopping malls, and coffee shops by
>   a diverse set of operators such as cellular network operators (GSM
>   and CDMA), Wireless Internet Service Providers (WISPs), and fixed
>   broadband operators.
> 
> As noted later on, these attributes are not limited to use with WLAN
> networks, but the relationship to user location is probably stronger
> with WLAN or LAN access than other access types.  I think you need
> to talk about this.
> 
>   When a user executes the network access authentication procedure to
>   such a network, information about the location and ownership of this
>   network needs to be conveyed to the user's home network to which the
>   user has a contractual relationship.
> 
> The use of the term "need" seems wrong here, since
> one of the goals of the document is to guard the privacy of location
> information, only providing it where there is "need to know".
> 
>   This document describes AAA attributes, which are used by a AAA
>   client or a AAA proxy in an access network, to convey location-
>   related information to the user's home AAA server.
> 
> The use of the term "AAA" here is a bit confusing.  If the attributes
> are applicable to both RADIUS and Diameter, this should be explicitly
> stated.
> 
>   Although the proposed attributes in this draft are intended for
>   wireless LAN deployments, they can also be used in other types of
>   wireless and wired networks whenever location information is
>   required.
> 
> I'd suggest this paragraph be combined with the first paragraph.
> 
>   Location information needs to be protected against unauthorized
>   access and distribution to preserve the user's privacy. [10] defines
>   requirements for a protocol-independent model for the access to
>   geographic location information.  The model includes a Location
>   Generator (LG) that creates location information, a Location Server
>   (LS) that authorizes access to location information, a Location
>   Recipient (LR) that requests and receives information, and a Rule
>   Maker (RM) that provides authorization policies to the LS which
>   enforces access control policies on requests to location 
> information.
> 
> I would talk a bit more about the privacy model in general terms, such
> as what protections it is designed to provide.
> 
> Section 2
> 
>   Based on today's protocols we assume that the location 
> information is
>   provided by the access network where the end host is attached.  As
>   part of the network attachment authentication to the AAA server
>   location information is sent from the AAA client to the AAA server.
> 
> Earlier, the document refers to use by a AAA proxy.  Could you say
> a few words about where the information originates (e.g. may originate
> on the NAS, or may be added a proxy).  Somewhere it is also worth
> stating that existing RADIUS attributes may also provide location
> information (e.g. NAS-Identifier).
> 
>   The authenticated identity might refer to a user, a device or
>   something else.  Although there might often be a user 
> associated with
>   the authentication process (either directly or indirectly; 
> indirectly
>   when a binding between a device and a user exists) there is no
>   assurance that a particular real-world entity (such as a person)
>   triggered this process.
> 
> Is the distinction between a user, device or machine identity
> relevant for the purposes of a privacy discussion?  This paragraph
> leaves me wondering whether there is a legal distinction that
> is relevant to the protocol design.
> 
>   Since location based authorization is
>   executed based on the network access authentication of a particular
>   "user" it might be reasonable to talk about user's privacy within
>   this document even though scenarios exist where this might not apply
>   (and device or network privacy might be the better term).
> 
> Maybe you need to define the term "user" in the document as being
> either a user, device or machine identity in order to clarify this.
> 
>   Furthermore, the authors believe that there is a 
> relationship between
>   the NAS (or other nodes in the access network) and the location of
>   the entity that triggered the network access authentication, such as
>   the user.
> 
> Why? If the NAS is a VPN server, then the user might be 
> located halfway
> around the world.  Might make more sense to say "depending on the
> type of access being provided, there may be a close relationship...."
> You might give examples:
> 
> 1) WLAN has limited range when deployed with an omni-directional
> antenna, so user is probably close to the NAS in geospatial
> (but not necessarily civil) terms.  Also, some WLAN
> access points can use "time of arrival" or other processing
> techniques to determine user location accurately;
> 2) In LAN access, the user can't be further away from the switch
> than cable length will permit.
> 3) Dialup or VPN user could be very far away from the NAS;
> 
> If you talk about this a bit, it might help clarify why the document
> is mostly for WLAN/LAN access.
> 
>   The NAS might in many cases know the location of the end
>   host through various techniques (e.g., wire databases, wireless
>   triangulation).  Knowing the location of a network (where 
> the user or
>   end host is attached) might in many networks also reveal enough
>   information about the location of the user or the end host.  A
>   similar assumption is also made with regard to the location
>   information obtained via DHCP (see for example [4]).
> 
> The DHCP case might be analagous to WLAN/LAN, but it is not analagous
> to the case of VPN or dialup access where the NAS and user could be
> separated by thousands of miles.
> 
>   This
>   information might be used by applications in other 
> protocols (such as
>   SIP [11] with extensions [12]) to indicate the location of a
>   particular user even though the location "only" refers to the
>   location of the network or equipment within the network.  This
>   assumption might not hold in all scenarios but seems to be 
> reasonable
>   and practicable.
> 
> I think you need to say that the assumption can be presumed to hold
> for certain values of the NAS-Port-Type attribute (e.g. LAN or
> WLAN access).  In others it may not hold.
> 
> Section 3
> 
>   Location Objects, which consist of location information and privacy
>   rules, are transported via the RADIUS protocol from the AAA 
> client to
>   the AAA server.  A few attributes are introduced for this 
> purpose, as
>   listed in Section 5, whereby delivery to the RADIUS server 
> can happen
>   during the authentication/authorization phase (described in
>   Section 3.1), or in the mid-session using the dynamic authorization
>   protocol framework (described in Section 3.2).  This section
>   describes messages flows for both delivery methods.
> 
> To me, it makes more sense to talk about what packets the location
> information can be delivered in, rather than "phases".  For example,
> location is delivered in Access-Request or Accounting-Request packets.
> Whether the Access-Request was triggered by dynamic authorization or
> a new user login is not important.  Also, this paragraph 
> seems to suggest
> that dynamic authorization is required to obtain mid-session location
> information.  Since location can be provided interim 
> accounting packets,
> this is not really true.  Perhaps the point is that dynamic 
> authorization
> allows the information to be provided on demand.
> 
> Section 3.1
> 
>   Figure 1 shows an example message flow for delivering location
>   information during the network access authentication and
>   authorization procedure.  Upon a network authentication request from
>   an access network client, the NAS submits a RADIUS Access-Request
>   message that contains location information attributes among other
>   required attributes.  These attributes are added based on various
>   criteria (such as local policy, business relationship with
>   subscriber's home network provider and in case of location
>   information also by considering privacy policies).
> 
> Even though Figure 1 mentions "out of band agreement" the text doesn't
> elaborate on what this means.
> 
> Since Figure 1 shows location information provided in
> an Accounting-Request, the first sentence isn't quite right.
> Given the privacy issues, I think you need to qualify what
> "location information" means in the second sentence. Do you
> mean that the user location is being supplied by the NAS?
> I think you need to say something about the default settings
> (e.g. location provided, or not?)  Backward compatiblity issues
> also probably deserve some discussion here. You might say
> a few words about when this flow might occur (e.g. challenge-incapable
> NAS).
> 
> Figure 1 uses the term "Network Access Client" which isn't
> defined in terminology or used in other RADIUS RFCs.  I would change
> all uses of this term to "User".
> 
>   If the AAA server needs to obtain location information also in
>   accounting messages then it needs to include a Requested-Info
>   attribute to the Access-Accept to express that is desired 
> (if privacy
>   policy allow it) and the Network Access Server SHOULD then include
>   location information to the RADIUS accounting messages .
> 
> I think you should say something about the packets within which the
> location information can be delivered in Section 1.  Something like:
> "This document enables a RADIUS server to request the delivery of
> location information within Access-Request packets, or additionally,
> within Accounting-Request packets."
> 
> Section 3.2
> 
> This section is problematic since it specifies RADIUS attribute
> usage prohibited by RFC 3576 Section 3, which states:
> 
>   Where a Service-Type Attribute with value "Authorize Only" is
>   included within a CoA-Request or Disconnect-Request, attributes
>   representing an authorization change MUST NOT be included; only
>   identification attributes are permitted.
> 
> If the desire is to change the location information being provided
> (e.g. to turn on location in accounting packets, or deliver different
> types of location) why couldn't a CoA-Request be sent without an
> "Authorization-Only" Service-Type?  If the desire is to request
> location immediately, couldn't this be encoded in the Request-Info
> attribute?  There seem to be ways to achieve the goal without
> violating RFC 3576.
> 
> Later on in the section, it is stated:
> 
>   Since location information can be sent in accounting records
>   (including accounting interim records), RFC 3576 [5] is only needed
>   for authorization changes.
> 
> Given this, it would appear that the need to obtain location 
> mid-session
> is best met by another technique, and that use of CoA-Request packets
> is only a corner case.  Given that RFC 3576 is not widely implemented,
> I'd expect the accounting approach to be more applicable, at least
> without an explanation about why this isn't a good idea (e.g. might
> not need location info with each interim accounting update).
> 
> Also, this section doesn't talk about when a RADIUS server can
> send a CoA-Request containing a Request-Info attribute.  Wouldn't
> this be restricted to cases where the NAS has previously included
> a Location-Information or Challenge-Capable attribute?
> 
> Section 4
> 
> I'm not clear this section should exist as a standalone 
> entity. It might
> be best to delete Section 4.2 entirely and integrate Section 4.1 with
> Sections 1 or 2.
> 
> Section 4.1
> 
>   The home network operator requires location information for
>   authorization and billing purposes.  The operator may deny 
> service if
>   location information is not available, or it may offer limited
>   service only.  The NAS delivers location information to the home AAA
>   server.
> 
>   The location of the AAA client and/or the end host is transferred
>   from the NAS to the RADIUS server (based on a pre-established
>   agreement or if the RADIUS server asks for it under consideration of
>   privacy policies).  The NAS and intermediaries (if any) are not
>   allowed to use that information other than to forward it to the home
>   network.
> 
> Are the terms "NAS" and "AAA client" used interchangeably 
> here?  If so,
> can we primarily use one term (NAS seems best)?
> 
>   The NAS and intermediaries (if any) are not
>   allowed to use that information other than to forward it to the home
>   network.
> 
> Intermediaries (e.g. AAA proxies) sometimes log Accounting-Request
> packets, since they may need them for billing purposes.  
> Since billing is
> one of the uses of location information, I don't think you 
> can prohibit
> that.  Also, what does it mean for the NAS to "use" location 
> information?
> Some NASes have stable storage, so they might write Accounting-Request
> packets to stable storage prior to delivery.  Or they might retain
> location information in memory.  Do you mean that that the 
> NAS or proxies
> can't provide the location information to unauthorized 
> parties?  Or do you
> mean that proxies MUST respect the privacy policies they 
> receive from the
> RADIUS server?
> 
>   The RADIUS server authenticates and authorizes the user requesting
>   access to the network.  If the user's location policies are 
> available
>   to the RADIUS server, the RADIUS server MUST deliver those policies
>   in an Access Accept to the RADIUS client.  This information MAY be
>   needed if intermediaries or other elements want to act as Location
>   Servers (see Section 4.2).  If the NAS or intermediaries do not
>   receive policies from the RADIUS server (or the end host 
> itself) then
>   they MUST NOT make any use of the location information other than
>   forwarding it to the user's home network.
> 
> I would name the specific attributes rather than just saying "location
> policies".  You are essentially saying that some attributes MUST be
> included in an Access-Accept packet.  The last sentence is somewhat
> more specific than just saying "allowed to use that information".
> 
>   Location Information may also be reported in accounting messages.
>   Accounting messages are generated when the session starts, stops and
>   periodically.  Accounting messages may also be generated when the
>   user roams during handoff.  This information may be needed by the
>   billing system to calculate the user's bill.  For example, there may
>   be different tariffs or tax rates applied based on the location.
>   Unless otherwise specified by authorization rules, location
>   information in the accounting stream MUST NOT be 
> transmitted to third
>   parties.
> 
> Most of this paragraph probably belongs in Section 1 of the document.
> I'm unsure what the last sentence means.  I think that the part of
> the last sentence from "location..." should probably be combined with
> the next sentence, to clarify it:
> 
>   Location information in the accounting stream MUST only be sent in
>   the proxy chain to the home network (unless specified otherwise).
> 
> For example, you might say "Location attributes contained within
> Accounting-Request packets MUST only be made available to entities
> on the proxy chain between the NAS and the home accounting
> server."
> 
> Section 4.2
> 
>   Location Servers are entities that receive the user's location
>   information and transmit it to other entities.  In this second
>   scenario, Location Servers comprise also the NAS and the RADIUS
>   server.  The RADIUS servers are in the home network, in the visited
>   network, or in broker networks.
> 
>   Unless explicitly authorized by the user's location policy, location
>   information MUST NOT be transmitted to other parties outside the
>   proxy chain between the NAS and the Home RADIUS server.
> 
>   Upon authentication and authorization, the home RADIUS server MUST
>   transmit the ruleset (if available) in an Access-Accept.  The RADIUS
>   client, intermediate proxies are allowed to share location
>   information if they received ruleset indicates that it is allowed.
> 
> Is a "Location Server" somehow different from an entity eligible
> to receive location information as described in the previous section?
> I'm unclear whether this section is saying anything different from
> Section 4.1 with respect to handling of user location information.
> 
> Section 5.1
> 
>   The Operator-Name attribute SHOULD be sent in Access-Request, and
>   Accounting-Request records where the Acc-Status-Type is set 
> to Start,
>   Interim, or Stop.
> 
> Is this attribute only sent in these packets?  If so, I would say:
> "MAY only be sent in Access-Request and Accounting-Request..."
> 
> The Value type is restricted to use with Integers.  I think that we
> are talking about a String here, no?
> 
> Section 5.2
> 
>   The Location-Information attribute SHOULD be sent in Access-Request
>   and in Accounting-Request messages.  For the Accounting-Request
>   message the Acc-Status-Type may be set to Start, Interim or Stop.
> 
> Is the intent that these attributes are only sent in Access-Request
> and Accounting-Request messages?  If so, say "MAY only be sent in..."
> 
> I think you are talking about a String type attribute, not an integer,
> right?
> 
>       The 16-bit unsigned integer value allows to associate
>       the Location-Information attribute with
>       Location-Info-Civic and Location-Info-Geo
>       attributes.
> 
> This is not a complete sentence. I think you need to explain that
> this attribute is used to provide information relating to the
> information included in the Location-Info-Civic and
> Location-Info-Geo attributes to which it refers (via the Index).
> 
> You should probably also state that this attribute is largely treated
> as an opaque blob, like the Location-Info-Civic and Location-Info-Geo
> attributes to which it refers.  As a result, it is not expected that
> RADIUS servers will need to change code to receive this attribute
> (although location applications would have to parse it).
> 
> Section 5.3
> 
>   Location-Info-Civic attribute SHOULD be sent in 
> Access-Request and in
>   Accounting-Request messages.  For the Accounting-Request message the
>   Acc-Status-Type may be set to Start, Interim or Stop.
> 
> Change to "MAY only be sent..." if that is the intent.
> 
> Please change "Value" to "String".
> 
>       The 16-bit unsigned integer value allows to associate
>       the Location-Info-Civic attribute with the
>       Location-Information attributes.
> 
> Is there an implication that multiple Location-Information attributes
> will have the same Index value?  That doesn't make sense to me.
> 
> Section 5.4
> 
>   Location-Info-Geo attribute SHOULD be sent in Access-Request, and
>   Accounting-Request records where the Acc-Status-Type is set 
> to Start,
>   Interim or Stop if available.
> 
> Change to "MAY only be sent" if that is the intent.
> 
> Change "Value" to "String"
> 
> Section 5.5
> 
> Should the title be "Basic-Policy-Rules Attribute"?
> 
>   Policy rules control the distribution of location location
>   information.  In some environments the the AAA client might know the
>   privacy preferences of the user based on pre-configuration or the
>   user communicated them as part of the network attachment.
> 
> This seems somewhat unlikely.  Do any existing access 
> protocols support
> user-provided privacy policies?  Or are we talking about generic
> NAS privacy settings here?
> 
> 
>   Basic-Policy-Rules attribute SHOULD be sent in an an Access-Request,
>   Access-Accept, an Access-Challenge, an Access-Reject and an
>   Accounting-Request message.
> 
> I think you mean "MAY be sent in an Access-Request..."
> 
>   o  The AAA client SHOULD NOT attach location information in the
>      initial Access-Request message but should rather wait for the AAA
>      server to receive a challenge for location information.
> 
> I think you mean "for the AAA server to send an Access-Challenge..."
> 
> I think you are instead saying that "absent NAS settings
> to the contrary, the default is..."  This probably should be 
> clarified.
> 
>   o  If a roamig agreement or legal circumstances require the AAA
> 
> roamig -> roaming
> 
>      client to transfer location information in the initial Access-
>      Request message to the AAA server (even though user specific
>      policies are not available to the AAA client) then the access
>      network attaches default authorization policies.
> 
> Are you saying that a Basic Policy Rules attribute MUST accompany
> a Location-Information, Location-Info-Geo or Location-Info-Civic
> attribute?
> 
>      The 'retransmission-allowed' flag MUST be set to '0' meaning
>      that the location must not be shared with other parties 
> (other than
>      forarding them to the user's home network).
> 
> Are we saying that sharing of location information is 
> controlled by the
> 're-transmission-allowed' flag and that parties MUST respect the flag?
> This seems to contradict earlier MUST statements (which seem to imply
> that sharing is not permitted, regardless of the flag value).
> 
>      In case the home
>      network knows the user's privacy policies then these policies
>      SHOULD be sent from the RADIUS server to the RADIUS client in a
>      subsequent response message and these policies will be applied to
>      further location dissemination and in subsequent RADIUS
>      interactions (e.g., when attaching location information to
>      Accounting messages).
> 
> What kind of response message?  Do you mean Access-Challenge here
> or Access-Accept? Is there a reason why a RADIUS server would refuse
> to disclose the user's privacy policies?  Should those policies
> ever be considered private?
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |  Flags                        | Retention Expires            ...
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Retention Expires                                            ...
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Retention Expires             | Note Well                    ...
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Note Well                                                    ...
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The design of this attribute is problematic.  It is different from
> other complex attributes in that it is sent by the RADIUS server,
> and the inclusion of timestamps implies that it needs to be computed
> dynamically, rather than treated as an opaque blob.
> 
> Also, there is an implication elsewhere in the document that the
> retransmission bit needs to be respected by RADIUS proxies.  Most
> existing RADIUS proxies cannot be configured to look at a specific
> octet in an attribute, so this will not be possible.
> 
> Is there a reason that this could not be split into separate
> unitary attributes, say, one for Retransmission, one for
> Retention-Expires and another for Privacy-Policy?  The 
> "Retention Expires"
> attribute would a 64-bit
> Long Integer, the Flags would be a 32-bit integer
> and the Note Well would be a string.
> 
> This would be much more compatible with the design of existing
> RADIUS servers and proxies and would enable privacy policies to
> be respected.
> 
> Section 5.6
> 
>   The Extended-Policy-Rules attribute SHOULD be sent in an Access-
>   Request, an Access-Accept, an Access-Challenge, an Access-Reject and
>   in an Accounting-Request message whenever location information is
>   transmitted.
> 
> Do we mean "MAY be sent" here?
> 
> I think "String" should be used here instead of "Value"
> 
> Why is Length >=4 (rather than 3)?
> 
> Section 5.7
> 
> Why is the Challenge-Capable attribute defined if it is always
> set to 0?  Is the presence of the attribute sufficient to indicate
> that the NAS is capable of being challenged so that the value
> is irrelevant?
> 
> It would make more sense for this to be a 32-bit integer value
> that only has a single value defined (1) indicating that the
> NAS is capable of being challenged.
> 
> Section 5.8
> 
>   The Requested-Info attribute allows the RADIUS server to indicate
>   whether it needs civic and/or geospatial location information of the
>   NAS or the end host (i.e., the entities that are indicated in the
>   Entity field of the Location-Information attribute).
> 
> Can't the RADIUS server ask for both NAS and end host information?
> 
>      2.  If the RADIUS server does not receive the requested
>          information in response to the Access-Challenge 
> (including the
>          Requested-Info attribute) then the RADIUS server 
> responds with
>          an Access-Reject with an Error-Cause attribute (including the
>          "Location-Info-Required" value).  Note that an Access-Reject
>          message SHOULD only be sent if the RADIUS server MUST use
>          location information for returning a positive access control
>          decision.
> 
> The combination of SHOULD and MUST is confusing.  I think you mean to
> say that an Access-Reject MUST only be sent if the RADIUS server
> requires location information, but does not receive it, right?
> 
>      This is typically the case when location
>      information is used for inclusion to the user's bill only.
> 
> Rephrase to "is used only for billing".
> 
>   If the RADIUS server does not send a Requested-Info attribute then
>   the RADIUS client MUST NOT attach location information to 
> messages to
>   the RADIUS server.  The user's authorization policies, if available,
>   MUST be consulted by the RADIUS server before requesting location
>   information delivery from the RADIUS client.
> 
> But earlier it is said that the NAS may send location information by
> default,
> correct?  Or is an exception being made?
> 
> Figure 11 probably belongs earlier in the document.
> 
>   The Requested-Info attribute MUST be sent by the RADIUS server if it
>   wants the RADIUS client to return civic and/or geospatial
>   information.  This Requested-Info attribute MAY appear in 
> the Access-
>   Accept or in the Access-Challenge message.
> 
> Earlier it seems to imply that the NAS could sent location information
> by out-of-band agreement.  So do you mean to say "in the absence of
> an out-of-band agreement..."?
> 
>     Requested-Info (64 bits):
> 
>       This text field contains an integer value that encodes the
>       requested information attributes.
>       Each capability value represents a bit position.
> 
> It would be clearer to just say that the Requested-Info attribute
> defines a bit field, where the information on CIVIC_LOCATION,
> GEO_LOCATION, USERS_LOCATION, and NAS_LOCATION can be requested.
> 
> BTW, why is a 64-bit value required?  wouldn't 32-bits do as well?
> 
> Section 6
> 
>   If multiple
>   Location-Information attributes are sent then they MUST NOT contain
>   the same information.
> 
> Does this mean "must not have the same Index field?" Or does it mean
> that they must not be identical in all respects?
> 
> Section 8.2
> 
>   o  The visited network is able to learn the user's identity.
> 
> I think you need a reference to NAI privacy (e.g. RFC 4282 or 
> 4372) here.
> 
> Section 8.3
> 
> This section interrupts the document flow; it would better belong in
> an Appendix.
> 
> Section 9
> 
>   Two entities might act as Location Servers as shown in Section 4, in
>   Figure 16 and in Figure 17:
> 
> I think the sentence should end with a period, not a colon, right?
> 
> Section 9.1
> 
>   In this scenario it is difficult to obtain authorization policies
>   from the end host (or user) immediately when the user 
> attaches to the
>   network.  In this case we have to assume that the visited network
>   does not allow unrestricted distribution of location information to
>   other than the intended recipients (e.g., to third party entities).
>   When the AAA messages traverses one or more broker networks, the
>   broker network is bound by the same guidelines as the 
> visited network
>   with respect to the distribution of location information.
> 
> Are you just saying that proxies need to respect the 
> 'retransmission' bit?
> In practice, they won't be able to do that because their 
> policy engines
> operate at the attribute, not bit level.  You'll need to have an
> individual attribute for retransmission if you want this to work.
> 
>   The visited network MUST behave according to the following
>   guidelines:
> 
>   o  Per default only the home network is allowed to receive location
>      information.  The visited network MUST NOT distribute location
>      information to third parties without seeing the user's privacy
>      rule set.
> 
> Are you saying that the lack of distribution is the default, absent
> receipt of privacy policies to the contrary?  I'd suggest that this
> be stated earlier on.
> 
>   o  If the RADIUS client in the visited network learns the basic rule
>      set or a reference to the extended rule set by means outside the
>      RADIUS protocol (e.g., provided by the end host) then it MUST
>      include the Basic-Policy-Rules and the Extended-Policy-Rules
>      attribute in the Access-Request message towards the home AAA
>      server.  Furthermore, the visited network MUST evaluate these
>      rules prior to the transmission of location information either to
>      the home network or a third party.  The visited network MUST
>      follow the guidance given with these rules.
> 
> This seems quite unlikely.  Is there a reference to a specification
> where this is proposed?
> 
>   o  If the RADIUS client in the visited network receives the Basic-
>      Policy-Rules attribute with Access-Accept or the Access-Challenge
>      message then the Basic-Policy-Rules MUST be attach in subsequent
>      RADIUS messages which contain the Location-Information attribute
>      (such as interim accounting messages).
> 
> attach -> attached
> You need to include this statement in the Attribute Table section 6.
> Doesn't it apply to all NASes, not just a visited network?
> 
>   o  If the RADIUS client in the visited network receives the 
> Extended-
>      Policy-Rules attribute with Access-Accept or the Access-Challenge
>      message then the Basic-Policy-Rules attribute MUST be attach in
>      subsequent RADIUS messages which contain the Location-Information
>      attribute (such as interim accounting messages).
> 
> attach -> attached
> 
> I think this needs to be included in the Attribute Table section 6.
> Doesn't it apply to all NASes, not just a Visited network?
> 
> Section 10
> 
>   If no authorization information is provided by the user
>   then the visited network MUST set the authorization policies to only
>   allow the home AAA server to use the provided location information.
> 
> This seems to contradict Figure 1 which shows location
> information sent by out-of-band agreement without any policy 
> attributes.
> 
>   It is necessary to use authorization policies to limit the
>   unauthorized distribution of location information.  The security
>   requirements which are created based on [10] are inline with threats
>   which appear in the relationship with disclosure of location
>   information as described in [33].  PIDF-LO [21] proposes S/MIME to
>   protect the Location Object against modifications.  S/SIME relies on
>   public key cryptography which raises performance, 
> deployment and size
>   considerations.  Encryption would require that the local AAA server
>   or the NAS knows the recipient's public key (e.g., the public key of
>   the home AAA server).
> 
> So are we saying that the location information attributes can 
> be encrypted
> in some cases, so that the privacy concerns are not 
> applicable? But the
> attributes don't support this, right?
> 
>   Knowing the final recipient of the location
>   information is in many cases difficult for RADIUS entities.
> 
> Specifically, RADIUS clients only deal with RADIUS servers 
> that are one
> hop away.
> 
> =============================================
> To: "Bernard Aboba" <[email-masked]>
> Subject: Re: Last Call: draft-ietf-geopriv-radius-lo 
> (Carrying Location 
> Objects in RADIUS
> From: Peter Nixon <[email-masked]>
> Date: Sun, 18 Feb 2007 13:18:57 +0200
> Cc: [email-masked], [email-masked], [email-masked]
> In-reply-to: <[email-masked]>
> References: <[email-masked]>
> User-agent: KMail/1.9.5
> 
> --------------------------------------------------------------
> ------------------
> 
> On Sun 18 Feb 2007 02:13, Bernard Aboba wrote:
> >Review of draft-ietf-geopriv-radius-lo-10.txt
> >
> >Overview comments:
> >
> >Overall, this document includes many normative statements relating
> >to privacy in a number of sections.   As it stands, this 
> makes it very
> >difficult to understand exactly what privacy support will be provided
> >in various scenarios.   I would strongly urge that these statements
> >be consolidated into a single section.
> >
> >In terms of RADIUS protocol usage, there are a few problems
> >(violation of a MUST NOT provision in RFC 3576, use of non-standard
> >RADIUS data types, inappropriate use of complex attributes)
> >
> >There are also a lot of editorial issues that need to be cleaned up.
> >
> >Given everything, this  document requires substantial  work before
> >it would be suitable for publication as an RFC.
> >
> >Section 1
> >
> >    Wireless LAN (WLAN) access networks are being deployed in public
> >    places such as airports, hotels, shopping malls, and 
> coffee shops by
> >    a diverse set of operators such as cellular network 
> operators (GSM
> >    and CDMA), Wireless Internet Service Providers (WISPs), and fixed
> >    broadband operators.
> >
> >As noted later on, these attributes are not limited to use with WLAN
> >networks, but the relationship to user location is probably stronger
> >with WLAN or LAN access than other access types.  I think you need
> >to talk about this.
> >
> >    When a user executes the network access authentication 
> procedure to
> >    such a network, information about the location and 
> ownership of this
> >    network needs to be conveyed to the user's home network 
> to which the
> >    user has a contractual relationship.
> >
> >The use of the term "need" seems wrong here, since
> >one of the goals of the document is to guard the privacy of location
> >information, only providing it where there is "need to know".
> >
> >    This document describes AAA attributes, which are used by a AAA
> >    client or a AAA proxy in an access network, to convey location-
> >    related information to the user's home AAA server.
> >
> >The use of the term "AAA" here is a bit confusing.  If the attributes
> >are applicable to both RADIUS and Diameter, this should be explicitly
> >stated.
> >
> >    Although the proposed attributes in this draft are intended for
> >    wireless LAN deployments, they can also be used in other types of
> >    wireless and wired networks whenever location information is
> >    required.
> >
> >I'd suggest this paragraph be combined with the first paragraph.
> >
> >    Location information needs to be protected against unauthorized
> >    access and distribution to preserve the user's privacy. 
> [10] defines
> >    requirements for a protocol-independent model for the access to
> >    geographic location information.  The model includes a Location
> >    Generator (LG) that creates location information, a 
> Location Server
> >    (LS) that authorizes access to location information, a Location
> >    Recipient (LR) that requests and receives information, and a Rule
> >    Maker (RM) that provides authorization policies to the LS which
> >    enforces access control policies on requests to location 
> information.
> >
> >I would talk a bit more about the privacy model in general 
> terms, such
> >as what protections it is designed to provide.
> >
> >Section 2
> >
> >    Based on today's protocols we assume that the location 
> information is
> >    provided by the access network where the end host is 
> attached.  As
> >    part of the network attachment authentication to the AAA server
> >    location information is sent from the AAA client to the 
> AAA server.
> >
> >Earlier, the document refers to use by a AAA proxy.  Could you say
> >a few words about where the information originates (e.g. may 
> originate
> >on the NAS, or may be added a proxy).  Somewhere it is also worth
> >stating that existing RADIUS attributes may also provide location
> >information (e.g. NAS-Identifier).
> >
> >    The authenticated identity might refer to a user, a device or
> >    something else.  Although there might often be a user 
> associated with
> >    the authentication process (either directly or 
> indirectly; indirectly
> >    when a binding between a device and a user exists) there is no
> >    assurance that a particular real-world entity (such as a person)
> >    triggered this process.
> >
> >Is the distinction between a user, device or machine identity
> >relevant for the purposes of a privacy discussion?  This paragraph
> >leaves me wondering whether there is a legal distinction that
> >is relevant to the protocol design.
> >
> >    Since location based authorization is
> >    executed based on the network access authentication of a 
> particular
> >    "user" it might be reasonable to talk about user's privacy within
> >    this document even though scenarios exist where this 
> might not apply
> >    (and device or network privacy might be the better term).
> >
> >Maybe you need to define the term "user" in the document as being
> >either a user, device or machine identity in order to clarify this.
> >
> >    Furthermore, the authors believe that there is a 
> relationship between
> >    the NAS (or other nodes in the access network) and the 
> location of
> >    the entity that triggered the network access 
> authentication, such as
> >    the user.
> >
> >Why? If the NAS is a VPN server, then the user might be 
> located halfway
> >around the world.  Might make more sense to say "depending on the
> >type of access being provided, there may be a close relationship...."
> >You might give examples:
> >
> >1) WLAN has limited range when deployed with an omni-directional
> >antenna, so user is probably close to the NAS in geospatial
> >(but not necessarily civil) terms.  Also, some WLAN
> >access points can use "time of arrival" or other processing
> >techniques to determine user location accurately;
> >2) In LAN access, the user can't be further away from the switch
> >than cable length will permit.
> >3) Dialup or VPN user could be very far away from the NAS;
> >
> >If you talk about this a bit, it might help clarify why the document
> >is mostly for WLAN/LAN access.
> >
> >    The NAS might in many cases know the location of the end
> >    host through various techniques (e.g., wire databases, wireless
> >    triangulation).  Knowing the location of a network 
> (where the user or
> >    end host is attached) might in many networks also reveal enough
> >    information about the location of the user or the end host.  A
> >    similar assumption is also made with regard to the location
> >    information obtained via DHCP (see for example [4]).
> 
> Also, If you consider 3G/GPRS networks, the NAS that a user 
> connects to is
> typically located in the main operations center of the 
> operator which means
> that the users location if most likely somewhere inside that country,
> however when the user roams (A large and growing number of 
> operator have
> GPRS/3G roaming agreements) they could in-fact be connecting 
> via an operator
> on the other side of the world, yet the NAS at most will know 
> the IP address
> of the SGSN (another device on GSM networks is involved in 
> the whole GPRS
> process, of which each operator has at least one) and will 
> not have an real
> idea where the user is at all...
> 
> Other devices in the network (Billing systems etc) may have 
> an "better" idea
> of where the user is (the country for example..) but they 
> also may not know
> this information until several weeks or months later (when billing
> information is exchanged between operators)
> 
> Cheers
> 
> --
> 
> Peter Nixon
> http://www.peternixon.net/
> PGP Key: http://www.peternixon.net/public.asc
> 
> 
>