Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sun, Sep 22, 2013 at 6:59 PM, Paul Wouters p...@cypherpunks.ca wrote: snip Note that decentralising makes you less anonymous. If everyone runs their own jabber service with TLS and OTR, you are less anonymous than today. So decentralising is not a solution on its own for meta-data tracking. When I'm talking about decentralizing of internet I'm talking more about the traffic flow. We are sort of already on the way there with CDN moving much used content close to the user, Microsoft updates are done this way afaik, youtube, think gmail are distributed to. I think this is mostly done due to cost and user-experience reasons. We should go further, end-users should be able to communicate with each other in a direct fasion as possible, preferable not going through central chokepoints at all. Why send a videosession between two neighbours 3000km just because they have different ISP that don't want to exchange local traffic local even they are in the same physical room with their equipment? In a rack next to each other? That is how internet in Norway are mostly done today with a very few exceptions. That means more interconnect between ISPs, more IX'es, and alot more distributed routing... ... but not sure if this is really in the IETF domain at all, is it a technical, economical or political issues that preventing this today? -- 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 21 September 2013 06:02, SM s...@resistor.net wrote: Hi Brian, At 21:54 19-09-2013, Brian E Carpenter 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. Thanks for writing the draft. For the sake of disclosure [1], I know some of the XSF members. draft-carpenter-prismatic-reflections-00 mentions that: Clearly, we have a lot of specification work ongoing in different areas that helps to mitigate various security vulnerabilities. This ranges from recent work on XMPP end-to-end security I recently read an article about XMPP ( https://www.eff.org/deeplinks/2013/05/google-abandons-open-standards-instant-messaging ). From the article: removes the option to disable the archiving of all chat communications What it removes is default disabling. It is still possible to disable all archiving, you just have to do it for each chat.
RE: Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
I've reviewed multiple iterations of this draft, and I believe it is mostly ready to go. However, the concerns I raised during WGLC in http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html regarding the ambiguity of some of the guidance regarding location of RPKI caches (close) in section 3 still have not been addressed. IMO if it is important enough to discuss proximity, it is important enough to devote some words to explaining the rationale for that recommendation so that operators can make an informed design decision. Thanks, Wes George -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Tuesday, September 17, 2013 10:52 AM To: IETF-Announce Cc: s...@ietf.org Subject: Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'RPKI-Based Origin Validation Operation' draft-ietf-sidr-origin-ops-21.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-10-01. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present those which are most critical. It is expected to evolve as RPKI-based origin validation continues to be deployed and the dynamics are better understood. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ballot/ No IPR declarations have been submitted directly on this I-D. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
NOMCOM 2013 - Call for Nominations
Dear Allison; Thank you very much for your e-mail message. I would like to ask is possible to nominate for more than one position. Please confirm. Thanks Hago Dafalla Sudan From: NomCom Chair nomcom-ch...@ietf.org To: IETF Announcement List ietf-annou...@ietf.org Cc: ietf@ietf.org Sent: Monday, 23 September 2013, 3:31 Subject: NOMCOM 2013 - Call for Nominations The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomco...@ietf.org. If use email, please include the word Nominate in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! NomCom 2013-14 will follow the policy for Open Disclosure of Willing Nominees described in RFC 5680. As stated in RFC 5680: The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential. Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2013/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomco...@ietf.org. Thank you for your help in identifying qualified nominees! Best regards, Allison Allison Mankin, Nomcom 2103-14 Chair, nomcom-chair-2...@ietf.org
Re: [urn] Open letter to WG participants (was: Re: Working Group Last Call of draft-ietf-urnbis-rfc2141bis-urn-06.txt)
At 08:10 19-09-2013, John C Klensin wrote: The WG will be three years old in late November. I hope and wish we could set a target of having the documents in the hands of the IESG well before that, ideally before Vancouver. From http://www.ietf.org/mail-archive/web/urn/current/msg01626.html If the WG does not make visible progress before IETF 82 (which I would measure by, at least, updated versions of the chartered I-Ds), as the responsible AD I will need to consider taking more drastic measures to generate a successful outcome, or consider closing the WG. And http://www.ietf.org/mail-archive/web/urn/current/msg01679.html I assume that the URNBIS WG will meet at IETF 83 in Paris (if the WG does not plan to meet then my concerns would become even more grave). Please note that WG sessions need to be scheduled less than 2 weeks from now: There were an issue about authorship. From http://www.ietf.org/mail-archive/web/urn/current/msg01843.html We have tried to standardize the URN syntax in Finland before, but failed (in about 2005 or so) when the external evaluators said that the draft was not compliant with URI syntax as defined in RFC3986. This time we do not want to take any risks. On the other hand, there is an urgent national need to revise RFC2141, since the government is planning to establish a URN service for the entire public sector. Currently the national library of Finland and its partners are assigning about 200.000 URNs annually to persistent digital resources; this figure is likely to rise. And http://www.ietf.org/mail-archive/web/urn/current/msg02062.html Today begins a two-week working group last call of draft-ietf-urnbis-rfc2141bis-urn-06.txt. This last call will end Tuesday, 27 August 2013. And http://www.ietf.org/mail-archive/web/urn/current/msg02120.html It is now over three weeks since the closing date and I, at least, have no idea where we are. Do the WG Chair(s) think we have consensus? Can the Finnish government rely on the IETF for technical standards? Regards, -sm
Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
However, the concerns I raised during WGLC in http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html regarding the ambiguity of some of the guidance regarding location of RPKI caches (close) in section 3 still have not been addressed. IMO if it is important enough to discuss proximity, it is important enough to devote some words to explaining the rationale for that recommendation so that operators can make an informed design decision. hey, thanks for caring and reviewing i think the two paragraphs you would like to see improved are As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. 'Close' is, of course, complex. One should consider trust boundaries, routing bootstrap reachability, latency, etc. If insecure transports are used between an operator's cache and their router(s), the Transport Security recommendations in [RFC6810] SHOULD be followed. In particular, operators MUST NOT use insecure transports between their routers and RPKI caches located in other Autonomous Systems. i am not against further explanation, send text. but short text. :) experiments have shown that latency between cache and router, and between caches in a cache dag, is not an appreciable issue. as the reports of these experiments are not peer reviewed, it is not clear that they are good to reference. one has been accepted at conext, but page count limit prevented the latency issue from being included :( i thought bootstrap reachability would be fairly obvious to an operator. but if simple routing and no dns dependency were not obvious to you, then a few words are indeed needed. or am i missing your point here? as the rpki-rtr protocol is beyond the border of object-based security, the operator only has transport security between the cache(s) and the router. it would probably be good to add this as it motivates the close and trust boundary cautions. what is missing from the second paragraph? section 7 of rfc6810, as referenced, was very heavily reviewed and pretty much bludgeons this one to death. of course if you have specific ideas for improvement, that'd be great. ok, we're going to stick it in a VM on our two national data center compute infrastructures like the rest of our servers, we can spin up more instances if you need to scale it but RFC mumble mumble says that we shouldn't do that... ok, why? And where do you want to put it? ummm... 'close' to the routers? Because...reasons i am not sure it would be useful to go into the general issue of why caches should be proximal to the consumer as it is a rather well- explored area, from akamia and limelight to dns. but if you have a sentence or two that communicates this, send it over. randy
Gen-ART LC Review of draft-ietf-l2vpn-pbb-vpls-interop-05
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l2vpn-pbb-vpls-interop-05 Reviewer: Ben Campbell Review Date: 2013-09-23 IETF LC End Date: 2013-09-24 Summary: Ready for publication as an informational RFC. Major issues: None Minor issues: None Nits/editorial comments: -- Abstract: Please expand H-VPLS on first mention -- section 1, 1st paragraph: Please expand VPLS on first mention. -- section 4, 3rd to last paragraph: Different PBB access networks... The previous and subsequent paragraphs say PBBN access networks. Should this instance also say PBBN? -- section 4.3: 2nd paragraph says this scenario is applicable to Loosely Coupled Service Domains and Different Service Domains. The 4th paragraph mentions Tightly Does that mean the scenario also applies to Tightly Coupled Service Domains? (i.e. should it be added to the 2nd paragraph, or removed from the 4th?)
Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice
take two paragraphs and call back in the morning if you are still in pain :) randy In order that routers need not perform certificate validation, cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], does not provide object-based security to the router. I.e. the router may not validate the data cryptographically from well-known trust anchor. The router trusts the cache to provide correct data and relies on transport based security for the data received from the cache. Therefore the authenticity and integrity of the data from the cache should be well protected, see Section 7 of [RFC6810]. As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. 'Close' is, of course, complex. One should consider trust boundaries, routing bootstrap reachability, latency, etc. E.g. as the router can not validate the received data using a trust anchor, it should only accept data from caches it strongly trusts to provide valid data. And a router should bootstrap from a chache which is reachable without relying on other infrastructure such as DNS or routing protocols.
Gen-ART review of draft-ietf-siprec-architecture-08
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-siprec-architecture-08 Reviewer: Russ Housley Review Date: 2013-09-23 IETF LC End Date: 2013-10-01 IESG Telechat date: Unknown Summary: Major Concerns: The use of required in Section 3.2.4 is confusing to me. It says: In a basic session involving only audio there are typically two audio /RTP streams between the two UAs involved transporting media in each direction. When recording this media the two streams may be mixed at the SRC before being transmitted to the SRS or it may be required that the media streams are not mixed and are sent to the SRS as two separate streams. Is this a requirement that the SRC imposes on the SRS? Please clarify. Minor Concerns: The definitions include: Recording unaware User Agent (UA): A SIP User Agent that is unaware of SIP extensions associated with the Communication Session. Such Recording unaware UA will be notified that a session is being recorded or express preferences as to whether a recording should be started, paused, resumed or stopped via some other means that is out of scope of SIPREC. There is no definition of SIPREC. Perhaps it could simply say: ... is out of scope for the SIP media recording architecture. Note that SIPREC does occur a few other places in the document, and this approach to the replacement seems to work for them too. Of course, the alternative it to define SIPREC. Section 5 talks about encryption of the media stream, but it does not offer any suggestions about the protection of the stored media. I doubt that there is a simple bit of advice, but implementers should be warned against strong protection of the media during transmission and then providing no protection to the stored media. Other Comments: The introduction defines these two acronyms: Session Recording Client (SRC) and the Session Recording Server (SRS). However, they are spelled out many times throughout the introduction. These acronyms are not really used until after the definitions section. I suggest using them throughout the document. There is a period missing at the end of the first sentence in Section 3.1.2. In Section 3.2.2, it says: o Identifies the sessions that is to be recorded. ... This should say sessions that are to be recorded. There is a period missing at the end of the last bullet in Section 3.2.2.
Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-bgpsec-threats-06 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is on the right track, but has open issues described in the review. This draft describes the threat model for BGP Path Security. The draft generally reads well, but does contain quite a bit of serious security analysis of an important routing protocol and hence requires both security and routing expertise to fully understand. Major issue: This draft contains more than just a threat model. It also contains a high level security analysis of the security architecture/approach that applies the RPKI to secure use of BGP. That analysis appears to be good, but it's somehow disconnected from the rest of the sidr WG's work, by what I hope is simply a terminology problem: - This draft refers to the security architecture/approach for BGP as PATHSEC. - Many of the other sidr WG draft refer to that security as BGPsec In effect, the PATHSEC security architecture/approach appears to be implicit in this draft. Something's missing - if those two terms were meant to be the same, BGPsec should probably be used in this draft, otherwise, the relationship should be described. I've tagged this as a major issue, as it makes text like the following in Section 4.2 rather unclear: Stale Path Announcement: If PATHSEC-secured announcements can expire, such an announcement may be propagated with PATHSEC data that is expired. This behavior would violate the PATHSEC goals and is considered a type of replay attack. What is PATHSEC data? What are the PATHSEC goals? The statement in the abstract that We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI doesn't seem to answer these questions. Minor Issue: Section 4.4 seems somewhat loose on caching by RPs, considering the importance of that caching in countering a number of the attacks described in that section - in multiple cases, RP detection of an attack relies upon the RP noticing that something has changed at the publication point wrt the RP's cached copy in a fashion that should not have happened. Statements such as the RPKI calls for RPs to cache and RPs are expected to make use of local caches strike me as a weak foundation for the level of security dependence on that caching. A pointer to a SHOULD or MUST requirement for caching by RPKI RPs in another document would alleviate this concern; surely that language exists somewhere. Nits/editorial comments: Also in Section 4.4: (The RP would be very unhappy if there is no CRL for the CA instance anyway.) Please rewrite to describe how the RP reacts to failure to find a CRL - the RP surely does something in addition to becoming very unhappy ;-). Some of that may already be in the sentence immediately following the very unhappy text. idnits 2.12.17 complains about a missing reference: == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5] should be informatively referenced here - it was RFC 2385, which has been obsoleted by RFC 5925, which is referenced here. The fact that RFC 2385 is obsolete will generate a different idnits warning, which is ok to ignore. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Document: draft-ietf-l2vpn-vpls-mcast-14 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes multicast optimizations for VPLS via use of MPLS multicast distribution trees within the service provider (SP) network. In general, the techniques in this draft are an improvement, as they should typically result in reduction of SP network traffic required to carry the same level of multicast traffic originating from the VPLS edges. I have reviewed primarily for transport-related topics; while I don't have the expertise to review for MPLS and VPLS concerns, I'm confident in the expertise of this author team in those technologies. I found a couple of items that are effectively editorial: (1) The techniques in this draft appear to add an MPLS label to the stack in order to identify the MPLS multicast tree. Does that added label raise any MTU concerns in practice? (2) Two techniques used by this draft - replication of traffic within a multicast tree, and flooding of traffic (section 14) - could be employed as traffic amplifiers in denial of service attacks. A short discussion of this possibility and the applicability of countermeasures described in this draft, RFC 4761 and/or RFC 4762 would be good to add to the security considerations section. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
WG Review: MBONE Deployment (mboned)
The MBONE Deployment (mboned) working group in the Operations and Management Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-03. MBONE Deployment (mboned) Current Status: Active WG Chairs: Greg Shepherd gjs...@gmail.com Leonard Giuliano le...@juniper.net Technical advisors: Scott Bradner s...@harvard.edu Assigned Area Director: Joel Jaeggli joe...@bogus.com Mailing list Address: mbo...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mboned Archive: http://www.ietf.org/mail-archive/web/mboned Charter: The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet, inter-domain and single domain. This activity will include, but not be limited to: - Document deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of multicast technology. Create practice and experience documents that capture the experience of those who have deployed and are deploying various multicast technologies. - Based on reports and other information, provide feedback to other relevant working groups. - Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects. - Analyze the need for IPv4 - IPv6 multicast transition solutions - Develop tools, extend protocols and provide operational and implementation advice that assists in multicast administration, diagnostics, troubleshooting and deployment between/within native and non-native environments. - Development of routing and group membership protocols is out of scope. This working group may develop requirements and assist in review and feedback of documents in other working groups responsible for such protocols. Goals and Milestones Nov 2013Submit multicast transport guidelines for congestion control to IESG Nov 2013Submit Mtracev2 to IESG for Proposed Standards Nov 2013Submit Overview of Multicast in the Data Center to IESG for Informational
IPSECME Working Group Virtual Interim Meeting, Ocotber 9, 2013
The IPsecME Working Group will hold a virtual interim meeting on Wednesday, Oct. 9, 2013 via a phone bridge. The main goal of the meeting will be to advance the auto-discovery VPN solution. The time for the meeting is: 15:00 UTC 8:00 San Francisco 17:00 Berlin 18:00 Tel Aviv Duration: 1:30 hours. Agenda: - Detailed presentations of two AD VPN drafts: draft-detienne-dmvpn-00 and draft-mao-ipsecme-ad-vpn-protocol-02. - A short discussion of draft-ietf-ipsecme-esp-ah-reqts-01. Dial-in information will be posted on the mailing list: http://www.ietf.org/mail-archive/web/ipsec/current/maillist.html
