On Sep 8, 2012, at 7:31 PM, Paul Hoffman wrote:

> 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

OK.

Section 4.1:

Point #1: While less configuration required is better, I would like there to be 
some absolute requirements. Like, changing or adding a spoke requires no 
changes to other spokes. Or changing any node does not require changing any 
other nodes where the static configuration does not include that node.

Speaking of which, I think a good criterion for evaluating proposals is the 
amount of required static (or "manual") configuration.

Point #3: What is "tunnel binding"?

Point #4 is unclear. If spokes talk to other spokes, in what way are they 
spokes? Sounds like a mesh to me. If you mean that the administrator(s) begin 
by statically configuring a star topology, and it automagically morphs into a 
mesh, this should be said explicitly.

Point #6: I'm not sure what a handoff is. If it's a single host moving from 
behind one peer to behind another peer, I don't see how this can be required. 
VPN gateways are often combined with stateful firewalls, which typically refuse 
to allow a TCP connection to proceed. 

Point #9: I think there's an expired draft for an IPsec MIB. But that's not 
what I meant in Vancouver. We are adding dynamic changes to the configuration. 
These changes should be logged and reported to facilitate trouble-shooting. 
With static configuration, if you haven't touched the configuration and things 
stopped working, you can look at gateways failing, at network errors, expired 
certificates, or any number of other issues that administrators know about and 
can look for. A dynamically changing configuration is a new possible source for 
errors, one that is currently not reported. So if gateway A believes that 
packets to host H should be forwarded through gateway B, but gateway B applies 
a DROP rule to all such packets, we need reporting of the configuration changes 
on both gateways to see how this thing happened.

Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to