Hiya, On 22/04/18 20:18, Dave O'Reilly wrote: > Dear all, > > I hope it’s not inappropriate for me to step into this discussion, > On the contrary, it's entirely appropriate!
> but I would like to respond to a few of the points that have been > raised so far. For brevity I will incorporate my responses to the > various emails into a single email. > > The main point people are making: > ——————————————————————— > > There are several objections to the document scope (by Stephen > Farrell, Brian E Carpenter and Ted Lemon - quotations are not > necessary, I trust). > > In response I only point out that the intarea working group has > already adopted a document making recommendations that logging of > source port should be done (RFC6302/BCP162). The point I’m making > in this document is that: > > 1. source port logging is not routine, despite publication of RFC6302 > in 2011 - in other words the document has not had the hoped for > impact 2. what are the reasons for this 3. what additional > recommendations can be made to move this along > > Therefore I’m a little surprised by this response to a relatively > minor movement in an already published intarea position. See my answer to Med. > > However, if people are irreconcilably opposed to the scope of the "irreconcilably" is just rhetoric - I am opposed based on the arguments given, there's no need to try make that sound like it's unreasonable. > current document, then I propose as follows: > > a. Reject the call for adoption by the working group and move the > document back to the independent submission stream. I believe the > conflict review comments have already been adequately addressed in > draft -04 and publication will hopefully be possible there. b. Begin > a discussion here (or in whatever forum might be more appropriate) on > what would be an appropriate scope for a separate document to > consider the broader issues that are being raised by the various > commenters and see what sort of consensus can be reached. I offer to > contribute my opinion to that discussion. That's up to you, the ISE and the IESG and doesn't need any WG action. But I'm not clear - are you saying you no longer want the draft to be adopted? If that's the case, we're done with this thread. > > Other additional points: > ——————————————— > > From Stephen Farrell: > >> I do support consideration of how law enforcement investigations >> can be carried out, but not without a similar level of >> consideration of the real trade-offs between assisting law >> enforcement and commercial or other surveillance. At present, the >> draft is nowhere near sufficient in this respect. (Despite saying >> that "Clearly a balance needs to be struck between individual right >> to privacy and law enforcement access to data during criminal >> investigations" the draft is anything but balanced in that >> respect.) > > The document is not supposed to be an analysis of the privacy > implications of law enforcement access to data in general and, by the > way, nobody is talking about “assisting law enforcement and > commercial or other surveillance†- that’s a straw man. Sorry it is not a straw man. If the mechanism has that effect then it has that effect regardless of your intentions as an author. So it doesn't matter what the draft is "supposed to be" but rather what matters is what the draft says. > I do > address in section 9 the privacy implications of the specific > proposal I disagree with the above assertion. "mention" != "address" > (source port logging) as a solution to a specific problem > (carrier grade NAT and similar technologies) - a proposal that has > already been accepted by the intarea group in RFC6302/BCP162. > > However, I agree with you that a broader discussion within the IETF > of the balance between privacy and the societal need for law > enforcement access to data is certainly required. Expanding on a point Tom Herbert made - there are actually maybe O(10,000) in the set of LEAs worldwide - most countries have more than one entity that sets policy for such things even if there are national laws/guidelines. IMO if the IETF tried to enable access to all the data that all tens of thousands of LEAs would like, then we'd be doing a disservice and engineering Internet protocols that can't serve the privacy needs of users. There is a real conflict in requirements from different perspectives. > From what I can see > in my research so far, the philosophy within the IETF appears to > heavily favour privacy over other issues (such as societal rights or > rights of victims of crime - represented in this case by law > enforcement access to data). I cite as just two examples of this (and > believe me I can provide many more): > > - RFC4941 (Privacy extensions for stateless address auto > configuration in IPv6) - “by design†obfuscation of the source of > network traffic with no consideration of the crime attribution > implications - RFC6742 (Default address selection for Internet > Protocol version 6 (IPv6)) - recommending selection of temporary > addresses generated using RFC4941 over other options > > I think a discussion of the broader issue requires robust and vocal > representation of both sides and I am willing to adopt for the We don't do "representation" here - which I agree makes it hard for some people who support the traditional LEA position to take part in discussion. > purposes of such a discussion the, apparently unpopular, position > that while the right to privacy is very important it is not the only > right and a more nuanced consideration of the situation might be > worthwhile. I'd love to see a discussion of requirements (not mechanisms) in this space. IMO the "record it all just in case" type of requirement is no longer appropriate when logging related to Internet protocols, given current and likely future uses for Internet protocols. I'm not sure what'd be the best way to have such a discussion in the IETF context, nor if (many) others are interested in such a discussion. Cheers, S. > > From Brian E Carpenter: > >> I do have another comment about adoption. This is an IPv4 >> technology. Do we really want to spent IETF cycles on it? I'd >> prefer that we adopt >> https://tools.ietf.org/html/draft-george-ipv6-support-03 . > > I agree with you that this is an IPv4 problem. I mention in the > document (last paragraph of section 1) that migration to IPv6 would > make this problem go away but also I would like to emphasise that > this is a real problem being faced right now and it is something that > can’t be put off until IPv6 migration is complete. Whether or not > the IETF is the correct forum is not for me to say - all I’m trying > to do is make sure that at least the conversation takes place. > > Regards, daveor >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
