Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

2011-11-07 Thread Melinda Shore
On 11/07/2011 12:46 PM, Michael Richardson wrote: So, okay, so you want to do new work to replace work that's already been well defined, that uses DNS as the transport. Could always use SIP, and relegate DNS to discovery: http://www.cs.cornell.edu/people/francis/sigcomm07-nutss-final.pdf [I

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

2011-11-08 Thread Melinda Shore
On 11/08/2011 11:02 AM, Michael Richardson wrote: "Geoffrey" == Geoffrey Huang writes: Geoffrey> Is there a mechanism in DNS to communicate this kind of Geoffrey> policy? As I understand the example below, the Geoffrey> communication from hub-gw to spoke32 would be something

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

2011-11-08 Thread Melinda Shore
On 11/08/2011 04:18 PM, Galina Pildush wrote: NHRP is a protocol that is used to discover the shortest path > through an NBMA cloud.It does not, however, "speak" IPSec ... I don't believe that Michael was suggesting that there's a complete solution here, just that there's prior work on routing,

Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

2011-11-28 Thread Melinda Shore
On 11/28/2011 03:38 PM, Paul Hoffman wrote: - hubs can receive information from the spokes about what addresses the spoke gateways protect - hubs can proactively go out and find spokes and then ask what addresses each spoke gateway protects - something else It seems to me that the TURN exampl

Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

2011-11-28 Thread Melinda Shore
On 11/28/2011 04:31 PM, Michael Ko wrote: To establish a secure connection between two authorized network nodes, some of the critical management tasks that are required include the following: 1. Discover if the network nodes that a user is authorized to access are currently online and active. (On

Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)

2011-11-28 Thread Melinda Shore
On 11/28/11 5:21 PM, Michael Ko wrote: [mk] A "user" is a network node that wants to connect with a peer node, preferably in a direct end-to-end connection. (If you can suggest a better term than "user" that will cause less confusion, I will use it instead.) A "user" may not be "authorized" to co

Re: [IPsec] Moving Authentication Header (AH) to Historic

2011-12-29 Thread Melinda Shore
It seems to me that the NAT problem is a *NAT* problem, not an AH problem. I'd want to hear from the wireless guys that they think ESP NULL is a reasonable substitute for AH, too. More generally the only reason I can see for moving something to historic is if it's not implemented and the environ

Re: [IPsec] Moving Authentication Header (AH) to Historic

2011-12-29 Thread Melinda Shore
On 12/29/11 4:48 PM, Jack Kohn wrote: It will also help ending repeated "ESP-NULL versus AH" discussions on various mailing lists. That is, I think, the first truly compelling argument I've come across. This has been something of an energy sink. Melinda ___

Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible

2012-03-22 Thread Melinda Shore
On 3/21/12 11:30 PM, Yoav Nir wrote: So if one or both of the VPN peers are behind NAT, we need some 3rd-party or parties to broken the NAT traversal. We need: - a STUN (or STUN-like) server for punching the hole - storage for the discovered address and port In SIP these functions are done by the

Re: [IPsec] Traffic Visibility Future

2010-01-07 Thread Melinda Shore
On Jan 7, 2010, at 3:06 PM, Jack Kohn wrote: o In a steady state, where we are using WESP only for ESP-NULL, what should a middle box do when it sees ESP traffic, besides hyperventilating and throwing up? How would that information be used here? Do you want to specify middlebox behavior? In

Re: [IPsec] Traffic Visibility Future

2010-01-07 Thread Melinda Shore
On Jan 7, 2010, at 3:45 PM, Jack Kohn wrote: I am just trying to understand what a WESP powered middle box thats interested in deep inspecting packets, should do when it sees a native ESP packet. Should it make an attempt to parse it based on heuristics (which i completely resent) or should it tr

Re: [IPsec] HA/LS terminology

2010-03-23 Thread Melinda Shore
On Tue, March 23, 2010 9:46 am, Rodney Van Meter wrote: > I am *NOT* an expert on fault tolerance, but I have studied it a > little (long ago, if not so far away), and I worked on Network > Alchemy's fault tolerant implementation of an IPsec gateway (a decade > ago, and a little farther away). So,

Re: [IPsec] Issue #177. (was: HA/LS terminology)

2010-03-23 Thread Melinda Shore
On Tue, March 23, 2010 1:20 pm, Yoav Nir wrote: > - For the cluster with just one member doing IKE and IPsec, I propose > "hot-standby cluster" > - For the cluster with several members doing IKE and IPsec, I propose to > keep "load-sharing cluster" I think "failover" is in broader use than "hot st

Re: [IPsec] Issue #177. (was: HA/LS terminology)

2010-03-24 Thread Melinda Shore
On Tue, March 23, 2010 11:46 pm, Dan Harkins wrote: > Of course it's not the only reason. But you're missing the point. The > point is that the reason doesn't matter! You want to describe a particular > reason-- the "master" crashed and all state went over to the "hot > standby"-- > not the gener