Re: [IPsec] Call for agenda items
Hi Chair, We'd like to ask for a time slot to present our draft draft-zhang-ipsecme-multi-path-ipsec-02. Thanks. Regards, Will > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Paul Hoffman > Sent: Wednesday, October 17, 2012 10:39 PM > To: IPsecme WG > Subject: [IPsec] Call for agenda items > > Greetings again. We have a 2-hour time slot in Atlanta, which is way more > than we asked for. We don't need to be talking about > draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is > being sent to the AD for review. This is a call for agenda items. Strong > preference is given to those which are in the WG charter. > > draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully there > will be more discussion of it before the meeting > > --Paul Hoffman > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] FW: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-02.txt
Hi all, We have modified our multipath ipsec draft according to some of the comments from the mail list: - Added a section to discuss the reorder issue. - Compared with SA, instead of SA bundle. Your review and comments are highly appreciated. Will Regards, Shucheng LIU (Will) -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Monday, October 22, 2012 10:44 PM To: Will Liu (Shucheng) Cc: Tina TSOU; vzhang2...@yahoo.com Subject: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-02.txt A new version of I-D, draft-zhang-ipsecme-multi-path-ipsec-02.txt has been successfully submitted by Will Liu and posted to the IETF repository. Filename:draft-zhang-ipsecme-multi-path-ipsec Revision:02 Title: Multiple Path IP Security Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-zhang-ipsecme-multi-path-ipsec-02.txt Status: http://datatracker.ietf.org/doc/draft-zhang-ipsecme-multi-path-ipsec Htmlized: http://tools.ietf.org/html/draft-zhang-ipsecme-multi-path-ipsec-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-zhang-ipsecme-multi-path-ipsec-02 Abstract: This document presents one approach to enhance data protection when transmitting IPsec datagrams across the insecure networks. The method affords the stronger protection to the traffic by splitting it among a set of sub-tunnels. All the Security Associations (SAs) are set up independently for all sub-tunnels. Both the sending and receiving entity combine all the sub-tunnels to one clustered tunnel. As different sub-tunnel uses different crypto key materials and processing parameters, it may achieve the stronger protection of the traffic across the insecure networks. In addition, it could possibly bring more benefits in terms of the network control. The IETF Secretariat ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] updating ESP and AH requirements (was: Call for agenda items)
On Oct 22, 2012, at 4:55 PM, David McGrew (mcgrew) wrote: > One thing that deserves to be on the agenda is a discussion of the need to > update the ESP and AH crypto requirements, which have not been updated > since 2007, and to provide guidance on how to use ESP and AH to achieve > security goals. I have a draft proposing what that could look like, > draft-mcgrew-ipsec-me-esp-ah-reqts-00. This is off-charter, but I > believe that it is something that many people would agree is worth doing. You may be overstating that "many people" agree that it is worth doing, but it is certainly worth discussing. > Of course, comments on the detailed requirements are welcome as well. Your listing of TripleDES as "SHOULD NOT" without any cryptographic justification might raise some eyebrows. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] updating ESP and AH requirements (was: Call for agenda items)
Hi Paul, One thing that deserves to be on the agenda is a discussion of the need to update the ESP and AH crypto requirements, which have not been updated since 2007, and to provide guidance on how to use ESP and AH to achieve security goals. I have a draft proposing what that could look like, draft-mcgrew-ipsec-me-esp-ah-reqts-00. This is off-charter, but I believe that it is something that many people would agree is worth doing. Of course, comments on the detailed requirements are welcome as well. David On 10/17/12 10:38 AM, "Paul Hoffman" wrote: >Greetings again. We have a 2-hour time slot in Atlanta, which is way more >than we asked for. We don't need to be talking about >draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and >is being sent to the AD for review. This is a call for agenda items. >Strong preference is given to those which are in the WG charter. > >draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully >there will be more discussion of it before the meeting > >--Paul Hoffman >___ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft
Dan, I've exchange some emails with with Johannes Merkle about adding cipher suites to TLS. What he's agreed to do is to include only three points (BrainpoolP256r1, BrainpoolP384r1, and BrainpoolP512r1) in the draft. spt On 10/19/12 3:20 AM, Dan Harkins wrote: Sean, It was a two-part request. I'd like the IESG to follow the same process they followed for what became RFC 5114. Is there a way to get an RFC published to update this registry that does not need to go through the IESG? If not then the 2nd part is the critical one; if so then we can just end this fiasco now. regards, Dan. On Thu, October 18, 2012 7:58 am, Sean Turner wrote: Dan, There's not need to ask the IESG about the process to update the registry in question it's clear: RFC required. You can get an RFC through a WG, through an AD, or through the ISE. spt On 10/15/12 10:54 PM, Dan Harkins wrote: Hi Sean, On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: On 10/12/12 2:32 AM, Dan Harkins wrote: On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: I'm going to run my proposal and Michael's by the IESG on an informal telechat to see which one's got the best chance of getting through the process to resolve the IEEE's request. Can you ask the IESG to just do what it has done in the past? That is, just update the registry to include code points for new curves without any bizarre notes or pointers? No fuss, no mess, just a few new rows in a table. The worst that could happen if the IESG agrees to do that is that someone somewhere might use a brainpool curve with IKEv1. The odds are slim, but they're not zero. And if that happens then so what? Really. So what? The RFC 5114 example wasn't published to address another SDO request for a code point so I don't think it's the same situation. That's certainly a distinction but I don't see how that matters. You could also note that RFC 5114 added MODP groups as well as ECP groups. Also a distinction that really doesn't matter. Again, the SDO request is a _by-product_ of the opposition to just letting Johannes' draft update the registry. It is this same opposition that is creating these problems about notes and pointers and the concern over whether they will have the desired effect and what we should do to ensure they do. If this opposition had not materialized there never would've been another SDO request. It is the same situation, indulge me here a bit: What we had was another organization (NIST) came up with some new DH groups and there was a proposal to add them to both IKEv1 and IKEv2 registries. And now, quite similarly, there's another organization (the ECC Brainpool) that came up with some new DH groups and there was a proposal to add them to both IKEv1 and IKEv2 registries. When the proposal was made to add the NIST groups to the IKEv1 registry there was no hullabaloo over updating a deprecated protocol's registry and there was no concern that someone somewhere might use the NIST groups with IKEv1. But when Johannes made his proposal to add the ECC Brainpool curves to the IKEv1 registry there was all of a sudden a hullabaloo and much concern that someone somewhere might use the ECC Brainpool groups with IKEv1. So my request to you is to ask that the IESG consider what the process defined for updating this registry is (it's RFC required) and to note that there is precedence to update the registry of this deprecated protocol. So please ask the IESG to just approve a draft (either Johannes' or mine) for publication as an RFC to update this registry in the same manner that RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). Then there'd be no need for the IESG to have a discussion about the (de)merits of notes and pointers in registries and how best to ensure that no one nowhere ever even thinks about using an ECC Brainpool curve in IKEv1 and that certainly sounds like a better use of everyone's time. regards, Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft
Sean Turner writes: > Yes - you can ask the ISE (https://www.rfc-editor.org/indsubs.html) to > publish. I am not sure if that helps, as RFC 5742 section 3 will still put it to IESG, and IESG still needs to consider the document and decide which conclusion it will come with it: -- The IESG review of these Independent Submission and IRTF stream documents results in one of the following five types of conclusion, any of which may be accompanied by a request to include an IESG note if the document is published. 1. The IESG has concluded that there is no conflict between this document and IETF work. 2. The IESG has concluded that this work is related to IETF work done in WG , but this relationship does not prevent publishing. 3. The IESG has concluded that publication could potentially disrupt the IETF work done in WG and recommends not publishing the document at this time. 4. The IESG has concluded that this document violates IETF procedures for and should therefore not be published without IETF review and IESG approval. 5. The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. -- If those numbers are added to "Internet Key Exchange (IKE) Attributes" registry (hey, there is new xml version of the registry http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xml) then that would clearly be related to the IPsecME WG. This means IESG still needs to consider the document and decide whether it comes to conclusion 2 or 3. I.e. the document will still be considered by the IESG. Dan's question asked whether he can publish the RFC without it needing to go through the IESG, and I think for this specific item the answer is no, as there clearly is WG which this work is related to. >>Is there a way to get an RFC published to update this registry that >> does not need to go through the IESG? If not then the 2nd part is >> the critical one; if so then we can just end this fiasco now. I think it would be better (and faster) to solve this here and now, than waste time through the independent submission stream. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
