Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]

[SM <[e-mail]>]

Dear Med,
At 22:41 08-09-2011, [e-mail] wrote:
>The HOST_ID can enclose the origin source IPv4 address, IPv6 
>address, IPv6 prefix, vlan, random value, etc. The only requirement 
>on the HOST_ID is as mentioned in the I-D:
>
>         "It must be unique to each host under the same
>         IP address.  It does not need to be globally unique.  Of course,
>         the combination of the (public) IPv4 source address and the
>         identifier (i.e., HOST_ID) ends up being relatively unique.  As
>         unique as today's 32-bit IPv4 addresses which, today, can change
>         when a host re-connects."
>
>As such the HOST_ID does not reveal other information than the 
>source IP address if there is no NAT in the path.
>
>
>According to draft-morris-privacy-considerations-03,
>
>    "The following list contains examples of information that may be
>    considered personal data:
>
>    o  Name
>
>    o  Address information
>
>    o  Phone numbers, email addresses, SIP/XMPP URIs, other identifiers
>
>    o  IP and MAC addresses or other host-specific persistent identifiers
>       that consistently links to a particular person or small, well-
>       defined group of people
>
>    o  Information identifying personally owned property, such as vehicle
>       registration number"
>
>IP addresses and host-specific persistent identifiers are on the 
>same level and may be considered as personal data. This is why we 
>have the following in the draft:

I'll mention the paragraph below the one you quoted:

   "Searching only for those example as an indication for the need of
    privacy is, however, insufficient given that the list above is
    constantly growing and depends very much on the context.  An
    information element may not be sensitive in one context but
    considered very sensitive in another."

Identifiers are used in different protocols.  Some of the identifiers 
in the list mentioned above are necessary for the protocol to fulfill 
its intended function.  If we are talking about IP addresses, it is 
important to take into account the context in which it is being 
used.  In the draft, the identifier is being added by an 
intermediary.  And that is where it can become problematic.

>   "If the HOST_ID is persistent it may be used to track a host (similar to
>    persistent IP addresses)."

draft-boucadair-intarea-nat-reveal-analysis discusses about 
identification and addressing abuse issues and defines a HOST_ID 
identifier.  The discussion about privacy can be summarized as an 
analogy with source IP addresses.  You are saying that the HOST_ID 
can be an issue only if it is persistent.  I suggest that you give 
some thought to context and also the consent angle.

At 23:03 08-09-2011, [e-mail] wrote:
>Med: Just a 
>clarification,  draft-boucadair-intarea-nat-reveal-analysis does not 
>argue in favor of mandating the use of a HOST_ID  or not. It only 
>documents encountered issues, proposed solutions and their 
>limitations. Doing so would (hopefully) help IETF making a

BTW, the problem statement (Section 1.1) needs some more work.  The 
problem to be solved is not stated clearly.

>recommendation on the next steps in this area. Examples of next 
>steps may include:
>
>(1) Recommend a solution?:  but individual solutions need to discuss 
>potential impact on performance, mis-usage of the solution to reveal 
>other "sensitive" information, etc.

There is a privacy mailing list.  You could ask for some feedback 
about how the proposal affects privacy.  I don't know how helpful it 
may be as that list is not very active.

>(2) Add a conclusion to say: "IETF has documented the issues 
>(RFC6269) and has analyzed solution candidates but IETF believes CGN 
>should stay evil"?: The risk is the emergence of proprietary solutions.

Although I have an opinion about CGNs, I won't say it is "evil" as 
the discussion won't have a constructive tone then.

>(3) Add a statement like "IPv6 will solve this?": but this does not 
>mitigate the service brokenness to be encountered by subscribers 
>when address sharing will be deployed at large. The issues are also 
>valid for NAT64, etc.

IPv6 is not really a solution to everything.  It would be argued that 
someone designed a technology without giving adequate consideration 
to how it will break existing services; i.e. solving a problem at one 
layer while pushing other problems to higher layers.

BTW, you discussed about traceability in RFC 6269.  This draft takes 
a different approach.  It's not that it is the "wrong" approach.  It 
injects an intractable problem into the discussion.

Regards,
-sm