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
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
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,
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
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
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
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
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
___
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
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
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
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,
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
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
14 matches
Mail list logo