Re: [IPsec] New I-D on IKEv3
On Oct 18, 2012, at 2:26 AM, Dan Harkins wrote: > > Hi David, > > On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote: >> Hi Dan, >> >> The lack or EAP authentication would be a non-starter for us to implement >> this in our remote access VPN client. Why not support EAP authentication? > > What credential are you interested in using with EAP? I'm not David, but with remote access VPN into an enterprise network, it's usually the passwords stored on the directory they are using. These directory servers support EAP over RADIUS or DIAMETER to the VPN gateway. The PSK method in the draft requires the VPN gateway to know the password (or a hash thereof). EAP (even EAP-dragonfly) doesn't. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Call for agenda items
On Wed, October 17, 2012 7: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. I would be happy to discuss IKEv3. Please let me know if you'll put me on the agenda and I'll prepare some slides to talk to. Dan. > 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] New I-D on IKEv3
Hi Yoav, On Wed, October 17, 2012 11:52 am, Yoav Nir wrote: > Add a CFG payload to the list. Already noted! CFG and NAT indication. > By the time we add all the things that we feel must be in an IKEv3, would > it be any simpler than IKEv2? Yes, I believe so. Simpler, more clear, and easier to implement with a high degree of interoperability. Dan. > Yoav > > On Oct 17, 2012, at 8:36 PM, David Brownhill (dbrownhi) wrote: > >> Hi Dan, >> >> The lack or EAP authentication would be a non-starter for us to >> implement this in our remote access VPN client. Why not support EAP >> authentication? >> >> Regards, >> David >> >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Friday, October 12, 2012 7:02 PM >> To: ipsec@ietf.org >> Subject: [IPsec] New I-D on IKEv3 >> >> >> Hello, >> >> I just submitted a new I-D that defines version 3 of IKE. The goals of >> this draft are to make a more easily understood, and simpler protocol >> that has a high degree of probability of achieving interoperability. It >> should be easier to read, easier to understand, and easier to >> implement. >> To those ends it: >> >> - severely limits the negotiable parameters and options >> - no long-term IKE SA, it's one and done >> - has a simple state machine which, if followed, should ensure the >> implementation interoperates with other implementations >> - is a true peer-to-peer protocol >> >> Please take a look and send me your comments! If you plan on >> implementing this protocol then definitely contact me, I want to >> interoperate with you. >> >> regards, >> >> Dan. >> >> --- >> >>Filename: draft-harkins-ikev3 >>Revision: 00 >>Title: The (Real) Internet Key Exchange >>Creation date: 2012-10-12 >>WG ID: Individual Submission >>Number of pages: 41 >>URL: >> http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt >>Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 >>Htmlized:http://tools.ietf.org/html/draft-harkins-ikev3-00 >> >> >> >> ___ >> 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 >> >> Scanned by Check Point Total Security Gateway. > > ___ > 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] New I-D on IKEv3
Hi David, On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote: > Hi Dan, > > The lack or EAP authentication would be a non-starter for us to implement > this in our remote access VPN client. Why not support EAP authentication? What credential are you interested in using with EAP? Dan. > Regards, > David > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Dan Harkins > Sent: Friday, October 12, 2012 7:02 PM > To: ipsec@ietf.org > Subject: [IPsec] New I-D on IKEv3 > > > Hello, > > I just submitted a new I-D that defines version 3 of IKE. The goals of > this draft are to make a more easily understood, and simpler protocol > that has a high degree of probability of achieving interoperability. It > should be easier to read, easier to understand, and easier to implement. > To those ends it: > > - severely limits the negotiable parameters and options > - no long-term IKE SA, it's one and done > - has a simple state machine which, if followed, should ensure the > implementation interoperates with other implementations > - is a true peer-to-peer protocol > > Please take a look and send me your comments! If you plan on > implementing this protocol then definitely contact me, I want to > interoperate with you. > > regards, > > Dan. > > --- > > Filename: draft-harkins-ikev3 > Revision: 00 > Title: The (Real) Internet Key Exchange > Creation date: 2012-10-12 > WG ID: Individual Submission > Number of pages: 41 > URL: > http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt > Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 > Htmlized:http://tools.ietf.org/html/draft-harkins-ikev3-00 > > > > ___ > 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] New I-D on IKEv3
Add a CFG payload to the list. By the time we add all the things that we feel must be in an IKEv3, would it be any simpler than IKEv2? Yoav On Oct 17, 2012, at 8:36 PM, David Brownhill (dbrownhi) wrote: > Hi Dan, > > The lack or EAP authentication would be a non-starter for us to implement > this in our remote access VPN client. Why not support EAP authentication? > > Regards, > David > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan > Harkins > Sent: Friday, October 12, 2012 7:02 PM > To: ipsec@ietf.org > Subject: [IPsec] New I-D on IKEv3 > > > Hello, > > I just submitted a new I-D that defines version 3 of IKE. The goals of this > draft are to make a more easily understood, and simpler protocol that has a > high degree of probability of achieving interoperability. It should be easier > to read, easier to understand, and easier to implement. > To those ends it: > > - severely limits the negotiable parameters and options > - no long-term IKE SA, it's one and done > - has a simple state machine which, if followed, should ensure the > implementation interoperates with other implementations > - is a true peer-to-peer protocol > > Please take a look and send me your comments! If you plan on implementing > this protocol then definitely contact me, I want to interoperate with you. > > regards, > > Dan. > > --- > >Filename: draft-harkins-ikev3 >Revision: 00 >Title: The (Real) Internet Key Exchange >Creation date: 2012-10-12 >WG ID: Individual Submission >Number of pages: 41 >URL: > http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt >Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 >Htmlized:http://tools.ietf.org/html/draft-harkins-ikev3-00 > > > > ___ > 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 > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New I-D on IKEv3
Hi Dan, The lack or EAP authentication would be a non-starter for us to implement this in our remote access VPN client. Why not support EAP authentication? Regards, David -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan Harkins Sent: Friday, October 12, 2012 7:02 PM To: ipsec@ietf.org Subject: [IPsec] New I-D on IKEv3 Hello, I just submitted a new I-D that defines version 3 of IKE. The goals of this draft are to make a more easily understood, and simpler protocol that has a high degree of probability of achieving interoperability. It should be easier to read, easier to understand, and easier to implement. To those ends it: - severely limits the negotiable parameters and options - no long-term IKE SA, it's one and done - has a simple state machine which, if followed, should ensure the implementation interoperates with other implementations - is a true peer-to-peer protocol Please take a look and send me your comments! If you plan on implementing this protocol then definitely contact me, I want to interoperate with you. regards, Dan. --- Filename:draft-harkins-ikev3 Revision:00 Title: The (Real) Internet Key Exchange Creation date: 2012-10-12 WG ID: Individual Submission Number of pages: 41 URL: http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 Htmlized:http://tools.ietf.org/html/draft-harkins-ikev3-00 ___ 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] STRONG NUDGE: Revised AD VPN Requirements
Hi Chris, Thanks a lot for your comments, my points inline: On Wed, Oct 17, 2012 at 7:47 AM, Ulliott, Chris < chris.ulli...@cesg.gsi.gov.uk> wrote: > Apologies for the delay in replying... > > I think the Gateway to gateway use case (para 2.2) doesn't cover the > problem I'm suffering. What if the use case was reworded such that it says > something along the lines of: > > -- start -- > > A typical Enterprise traffic model is hub and spoke, with the gateways > connecting to each other using IPsec tunnels. > > However for the voice and other rich media traffic that occupies a lot of > bandwidth or is performance sensative, the traffic tromboning to the hub > can create traffic bottlenecks on the hub and can lead to an increase in > cost. A fully meshed solution is would make best use of the available > network capacity and performance but the deployment of a fully meshed > solution involves considerable configuration, especially when a large > number of nodes are involved. For the reasons of cost and manual error > reduction, it is desired that there be minimal configuration on each > gateway. VM> I agree adding the point of Full mesh having more configuration is an issue and will add it to the text. However another issue we see is that in a Full Mesh we need connectivity between all nodes which means that the weakest link is the Branch device, that is another reason we have a hub and spoke with the mesh cross connections on demand. It is highly desirable that the solution works where the endpoints are administrated by separate management domains, albeit, ones that have an existing trust relationship (for example two organisations who are collaborating on a project, they may wish to join their networks, whilst retaining independent control over configuration) VM> I agree we should state this in the requirement explicitly and is critical to the solution. When two gateways communicate, they must use a mechanism for authentication, such that they do not expose themselves to the risk of impersonation by the other entities. VM> Sounds good. -- end -- In section 3.2, it would be nice if we could again mention that rather looking for a solution that makes a star architecture work, actually enables a dynamic, fully meshed solution to be practical. VM> Agree.We call it star with temporary mesh connection, I agree we can call it dynamic mesh connectivity instead. In section 4.1, there are comments about minimising the configuration changes... should we word this a bit stronger and say that after initial configuration, there should be no need for a manual configuration change as devices (endpoint or gateways) are added, removed or changed? VM> I am ok with that, my point was we need to configure profiles when a device is added, we do not need to reconfigure if we find devices of the same profile. For the use case where end points need to find the optimum gateway to connect to, do we need a requirement that enables an endpoint to identify which is the best gateway to connect to, the nearest may not be the best, depending on the network cost behind the gateway... but this may be complicating the problem too much. VM> I think the problem of network cost is that of routing. We need a way for policy to determine when to transfer a connection from one gateway to another. The solution should allow for such signalling though. Thoughts? VM> Great comments, which I can see come from real world usecases. Thanks, Vishwas Chris > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Paul Hoffman > Sent: Saturday, September 08, 2012 5:31 PM > To: IPsecme WG > Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements > > This appeared on the list over two weeks ago and it has received no > comments since. This is supposed to be the WG's main work item, folks. > > --Paul Hoffman > > On Aug 23, 2012, at 9:02 AM, Stephen Hanna wrote: > > > Vishwas and I have updated the AD VPN Problem Statement > > and Requirements draft to address the comments received > > on the previous version and remaining comments from > > earlier email discussions. The new version is available at > > > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem > > > > A summary of the changes in this version is included at > > the end of this message. > > > > Please review this document and provide any comments on > > the existing requirements or suggestions for new ones. > > > > For requirement 3, Vishwas will be starting an email > > thread soon so that the WG can discuss what this text > > means, whether we want to keep it, and how it can be > > made clearer. > > > > Thanks, > > > > Steve > > > > > > > > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt > > > > * Changed draft name from p2p-vpn to ad-vpn. > > > > * Added a paragraph for each requirement, explaining how > > that requirement is driven by the use cases. > > > > * In requirement 1, defined what we m
Re: [IPsec] Call for agenda items
On Oct 17, 2012, at 8:09 AM, Yoav Nir wrote: > Are we going to have a contest for a solution document, similar to the one > they had at httpbis? Not in Atlanta, no, but maybe afterwards. To the best of my understanding, none of the proposals that we heard earlier have updated their drafts to say how they cover or don't cover what's in the requirements and scenarios document. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Call for agenda items
On Oct 17, 2012, at 4:38 PM, 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. Are we going to have a contest for a solution document, similar to the one they had at httpbis? Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Call for agenda items
On Oct 17, 2012, at 7:52 AM, Yaron Sheffer wrote:
> A quick correction: the latest version of the now-finished draft has been
> renamed draft-ietf-ipsecme-ad-vpn-problem ("auto-discovery VPN",
> http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00).
Whoops, yes. An artifact of my sometimes-too-helpful personal document tracking
system.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Call for agenda items
A quick correction: the latest version of the now-finished draft has
been renamed draft-ietf-ipsecme-ad-vpn-problem ("auto-discovery VPN",
http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00).
Thanks,
Yaron
On 10/17/2012 04:38 PM, 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] STRONG NUDGE: Revised AD VPN Requirements
Apologies for the delay in replying... I think the Gateway to gateway use case (para 2.2) doesn't cover the problem I'm suffering. What if the use case was reworded such that it says something along the lines of: -- start -- A typical Enterprise traffic model is hub and spoke, with the gateways connecting to each other using IPsec tunnels. However for the voice and other rich media traffic that occupies a lot of bandwidth or is performance sensative, the traffic tromboning to the hub can create traffic bottlenecks on the hub and can lead to an increase in cost. A fully meshed solution is would make best use of the available network capacity and performance but the deployment of a fully meshed solution involves considerable configuration, especially when a large number of nodes are involved. For the reasons of cost and manual error reduction, it is desired that there be minimal configuration on each gateway. It is highly desirable that the solution works where the endpoints are administrated by separate management domains, albeit, ones that have an existing trust relationship (for example two organisations who are collaborating on a project, they may wish to join their networks, whilst retaining independent control over configuration) When two gateways communicate, they must use a mechanism for authentication, such that they do not expose themselves to the risk of impersonation by the other entities. -- end -- In section 3.2, it would be nice if we could again mention that rather looking for a solution that makes a star architecture work, actually enables a dynamic, fully meshed solution to be practical. In section 4.1, there are comments about minimising the configuration changes... should we word this a bit stronger and say that after initial configuration, there should be no need for a manual configuration change as devices (endpoint or gateways) are added, removed or changed? For the use case where end points need to find the optimum gateway to connect to, do we need a requirement that enables an endpoint to identify which is the best gateway to connect to, the nearest may not be the best, depending on the network cost behind the gateway... but this may be complicating the problem too much. Thoughts? Chris -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Hoffman Sent: Saturday, September 08, 2012 5:31 PM To: IPsecme WG Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements This appeared on the list over two weeks ago and it has received no comments since. This is supposed to be the WG's main work item, folks. --Paul Hoffman On Aug 23, 2012, at 9:02 AM, Stephen Hanna wrote: > Vishwas and I have updated the AD VPN Problem Statement > and Requirements draft to address the comments received > on the previous version and remaining comments from > earlier email discussions. The new version is available at > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem > > A summary of the changes in this version is included at > the end of this message. > > Please review this document and provide any comments on > the existing requirements or suggestions for new ones. > > For requirement 3, Vishwas will be starting an email > thread soon so that the WG can discuss what this text > means, whether we want to keep it, and how it can be > made clearer. > > Thanks, > > Steve > > > > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt > > * Changed draft name from p2p-vpn to ad-vpn. > > * Added a paragraph for each requirement, explaining how > that requirement is driven by the use cases. > > * In requirement 1, defined what we mean by minimizing > configuration changes. > > * In requirement 2, explained that this requirement implies > that SPD entries and other configuration based on peer > IP address will need to be automatically updated when > the peer's IP address changes. > > * Split requirement 4 into two requirements (now 4 and 5). > > * In requirement 6 (formerly 5), explained what we mean > by "easy handoff of sessions": avoid TCP session breakage > and packet loss, when possible. > > * In requirement 8 (formerly 7), acknowledged the difficulty > of handling cases where gateways are behind NATs or where > two endpoints are both behind separate NATs. In those cases, > we may need to use workarounds such as port forwarding by > the NATs or falling back to a hub and spoke architecture. > > * Added new requirement 9 around manageability. > > * Added new requirement 10 around cross-organization use. > > * Added new requirement 11 saying that administrators should > be able to limit topologies for security and other reasons. > > * Fixed typos and other minor wording issues. > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing
[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
