On Mar 8, 2014, at 7:03 AM, Brian E Carpenter <[email protected]> wrote:
> Dan, > > On 08/03/2014 09:31, Dan Wing wrote: >> On Mar 6, 2014, at 6:03 PM, Brian E Carpenter <[email protected]> >> wrote: >> >>> a) Since this is fixing some of the damage done by NAT, it's >>> really unfinished business for BEHAVE, which if iirc was a >>> Transport Area WG. Just saying... >>> >>> b) The word "privacy" doesn't appear in the draft. Discussing >>> privacy aspects is clearly essential if there is any thought of >>> advancing this work. Actually I doubt if such a host ID is ever >>> going to be acceptable from a privacy point of view, unless the >>> end system is at liberty to change it at random (like RFC 4941). >> >> I interpret your statement to mean that address sharing is a desirable >> security property. If that interpretation is correct, where does that leave >> IPv6? > > I'm not sure where you found that in what I wrote. The authors can probably pull or copy text from RFC6967's Section 3 and its Security Considerations. > I think that address > sharing is undesirable from every point of view; I suppose it > might reduce the risk of layer 3 based tracking of users, > but that's certainly not what I meant. Address sharing does reduce the risk of layer 3 tracking. Combined with port randomization between subscribers ("NAPT"), it can do a pretty helpful job if that is the intent. > IPv6 with RFC 4941 (which > appears to be deployed in the vast majority of IPv6 clients today) > is fine from this point of view. Not really. But that is a different discussion; perhaps we should have that discussion somewhere. > I don't see any difference in > privacy effect between a randomly-changing shared-IPv4 Host ID and > a randomly-changing IPv6 address. The difference is scope: can the traffic be identified to a single home (IPv6 /64 address; IPv4 /32 address; or a PSTN telephone number), or can the traffic only be identified to a region within a city (HTTP caching proxy; carrier grade NAT). >>> c) A hard-nosed argument is that since we want to sunset IPv4, >>> it's time to stop working on ways of making NAT solutions work >>> better. Is there anything in the use cases that can't be fixed by >>> native IPv6? >> >> Yes, attackers won't move to IPv6 if IPv4 provides them a superior way to >> hide their activities. There are attackers already using IPv4 CGN to >> obfuscate themselves. > > Attackers will move to IPv6 when their targets do so. I guess > such attackers will find RFC 4941 useful too. What's good for > the privacy of legitimate users is also good for the privacy > of attackers. -d > Brian > >> -d >> >> >>> (The use case in expired draft >>> http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 >>> is not at all convincing to me, especially when adding the privacy >>> argument. It actually seems to describe a bug in 3GPP. But in any case, >>> the draft appears to suggest mitigations.) >>> >>> Regards >>> Brian >>> >>> On 07/03/2014 05:28, joel jaeggli wrote: >>>> Greetings int-area and hiaps-mailing-list folks, >>>> >>>> I realize that this is midweek at the IETF, however this question is not >>>> far from several discussions I've had this week. >>>> >>>> I have been asked to consider AD sponsoring >>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 >>>> >>>> In the process of considering doing so I'd like to get some input with >>>> respect to: >>>> >>>> A. The appetite for pursuing some or any of this work in existing >>>> working groups, and in particular within the INT area. >>>> >>>> B. A consensus basis for moving beyond RFC 6269 into active work in this >>>> area. >>>> >>>> C. How we address concerns raised by the IETF community expressed >>>> through draft-farrell-perpass-attack when evaluating scenarios and >>>> beginning to address requirements and solution-space. >>>> >>>> Obviously these are complex questions and I do not expect that we will >>>> arrive at answers easily nor does work on this or other drafts depend on >>>> answering them, however it's part of the dialog. >>>> >>>> Thanks >>>> joel >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Int-area mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/int-area >>> _______________________________________________ >>> Int-area mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/int-area >> >> . >> _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
