Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 09/21/2013 02:42 PM, Roger Jørgensen wrote: On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. FWIW, I'm also maintaining a list of concrete proposals and relevant I-Ds that I've seen. [1] I've not noticed an I-D on the LISP idea though but let me know if there's one I missed. S. [1] http://down.dsg.cs.tcd.ie/misc/perpass.txt
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sat, Sep 21, 2013 at 7:24 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 09/21/2013 02:42 PM, Roger Jørgensen wrote: snip There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. FWIW, I'm also maintaining a list of concrete proposals and relevant I-Ds that I've seen. [1] I've not noticed an I-D on the LISP idea though but let me know if there's one I missed. are no new I-Ds yet no.. :( -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: Last Call: draft-ietf-opsec-ip-options-filtering-05.txt (Recommendations on filtering of IPv4 packets containing IPv4 options) to Best Current Practice
On Mon, 16 Sep 2013, The IESG wrote: The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Recommendations on filtering of IPv4 packets containing IPv4 options.' draft-ietf-opsec-ip-options-filtering-05.txt as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-30. I would like to see the following issues addressed before this document is approved for publication. I have suggested specific replacement text in most cases, but I recognize that there are other ways to address the concerns that I raise. Sections 4.3 (LSRR) and 4.4 (SSRR): OLD: 4.3.5. Advice Routers, security gateways, and firewalls SHOULD implement an option- specific configuration knob whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be drop, and the default setting MUST be documented. NEW: 4.3.5. Advice Routers, security gateways, and firewalls SHOULD implement an option- specific configuration knob whether packets with this option are dropped or whether packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be drop, and the default setting MUST be documented. The same change should be applied to 4.4.5. Rationale: pretending that the option is not present will result in violation of the semantics of the option. More specifically, if a node is specified in the dettination address of the IPv4 header ignores an unexpired source route option, then it will consume a packet that is actually addressed to another node. Section 4.6 (Stream ID): Editorial: OLD: However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems. See also Section 5. NEW: However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems. Rationale: Section 5 is the IANA Considerations section. RFC 6814 requested IANA to mark this option as obsolete, and that has been done. No change is needed to Section 5 as it does not request any actions from IANA. Misuse of RFC 2119 language: Section 4.6.3, Threats, says: No specific security issues are known for this IPv4 option. while Section 4.6.5, Advice, says: Routers, security gateways, and firewalls SHOULD drop IP packets containing a Stream Identifier option. Note that RFC 2119, Section 6 says: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions). For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. The document does not identify any interoperability problems or potential harm that would be mitigated by dropping packets with this option. The SHOULD in Section 4.6.5 is therefore unjustified. Possible fixes: either provide a valid justification for the SHOULD, change it to a MAY, or specify that the Stream ID option SHOULD be treated in the same manner as an unknown option, i.e., as specified in Section 4.23.4. My vote would be for the latter; possible replacement text along those lines is as follows: NEW: 4.6.5. Advice Routers, security gateways, and firewalls SHOULD process IP packets containing this option in the same manner as those containing unknown options (see Section 4.23.4). Section 4.7: The Internet Timestamp option has similar uses as the Record Route option, and should be treated similarly. Specifically: OLD: 4.7.1. Uses This option provides a means for recording the time at which each system processed this datagram. NEW: 4.7.1. Uses This option provides a means for recording the time at which each system (or a specified set of systems) processed this datagram, and may optionally record the addresses of the systems providing the timestamps. OLD: 4.7.4. Operational and Interoperability Impact if Blocked None. 4.7.5. Advice Routers, security gateways, and firewalls SHOULD drop IP packets containing an Internet Timestamp option. NEW: 4.7.4. Operational and Interoperability Impact if Blocked Network troubleshooting techniques that may employ the Internet Timestamp option (such as ping with the
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sat, 21 Sep 2013, Stephen Farrell wrote: On 09/21/2013 02:42 PM, Roger Jørgensen wrote: On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. FWIW, I'm also maintaining a list of concrete proposals and relevant I-Ds that I've seen. [1] I've not noticed an I-D on the LISP idea though but let me know if there's one I missed. It's a draft from 1998: http://tools.ietf.org/html/draft-ietf-ipsec-internet-key-00 I'm considering implementing something like that for the next version of libreswan. But if we resurrect this draft, it needs work to get modernized or be started as a complete rewrite from scratch. For exaple, we'd have to ensure that these connections remain sandboxed to the machine, and that any IP assignments are not leaking outside the machine (in the light of NAT based inner IPs, etc) Paul
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Mark Nottingham wrote: Then, protocols not have any authoritative specification and should never be standardized and there should be no central authority to manage different versions of the protocols. From a PRISM viewpoint, the cost of parsing different formats, understanding different wire protocols, etc. is trivial. That is a reasoning to deny the point of you: : I draw the opposite conclusion, actually. With good standards, ; we can encourage a larger number of services to exist, : raising the cost of monitoring them all. So, denying the point, you agree with me. Note that the number of services != the number of service providers. The real cost is negotiating with / bullying each provider into giving access. Especially if it's not hosted or doing business in a country you control. If only the number of cloud providers were large. However, as there is some scale merit, there is a tendency that the number of the providers will be small and all of the providers naturally have considerable amount of hardware at the central part of the Internet, that is, in US, which means the providers are subject to USG control. And, USG is not the only government we should be protected from. I should be able to choose my own data sync server, whether it's one I run, or one run by my paranoid friend, or by a local company, or a US company that's in bed with the NSA. The only secure way is to run your own. That's a very simplistic definition of secure. See above how simplistic your view is against so complex nature of PRISM etc, against which, only the simplest protection is effective. Masataka Ohta
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, September 19, 2013 9:55 PM To: IETF discussion list Subject: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt] I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian Original Message Subject: I-D Action: draft-carpenter-prismatic-reflections-00.txt Date: Thu, 19 Sep 2013 21:47:18 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Prismatic Reflections Author(s) : Brian Carpenter Filename: draft-carpenter-prismatic-reflections-00.txt Pages : 9 Date: 2013-09-19 Abstract: Recent public disclosure of allegedly pervasive surveillance of Internet traffic has led to calls for action by the IETF. This draft exists solely to collect together a number of possible actions that were mentioned in a vigorous discussion on the IETF mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-prismatic-reflections There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-prismatic-reflections-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian, This is a useful summary, but I would like to see a few additions: 1) Encourage protocol designs that rely on peer-to-peer transmission, rather than intermediate relays, because relays are natural targets for interception services. 2) Encourage distributed services over centralized services. For example, social networking services today are heavily centralized. A distributed architecture would allow distribution of data at multiple location, managed by different commercial companies and covered by different legal authorities. 3) Require security sections of new RFC to include mass surveillance in their threat model and consider mitigations. -- Christian Huitema
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On 9/21/2013 9:40 PM, Christian Huitema wrote: 1) Encourage protocol designs that rely on peer-to-peer transmission, rather than intermediate relays, because relays are natural targets for interception services. Unless you are interacting on the same local net segment, when is Internet communications not through a relay? Router, MTA, Web cache, whatever. Given that, ultimately, there are always routers, what is the realistic improvement you are suggesting? 2) Encourage distributed services over centralized services. For example, social networking services today are heavily centralized. +1 Except that essentially all services other than email have gained popularity in centralized form, including IM. So there appear to be some important and difficult operational and usability barriers, standing in the way of more truly distributed applications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
