Hi Praveen, Comments inline.
Thanks, Fred (sent from mobile) > > [PRAVEEN] I think you didn’t get my answer. What I was trying to say is, > if there is a network prefix change on the spoke side, Spoke renegotiates > with Hub (Child SA rekey has TSi and Tsr payload to convey about the > address change). Thus Hub would know about the change, without any > administrator intervention. There is no file/database to be edited. This > is quite similar to what routing protocol would do. I think this is getting clearer now. Thanks. So based on what you say above and below, when the spoke updates its new TSi TSr, all traffic is potentially blocked until the admin vouches the change in the protected domain list ? > [PRAVEEN] It all depends on how you implement. It can be automated as > well, if you like to do so. For example, each spoke when establishes a > tunnel with the Hub, Hub already knows about the prefixes that spokes > protects. This information can be populated to PROTECTED_DOMAIN database > automatically. You don’t need any administrator intervention, if you > really want to trust such changes. Thanks for that. I meant the PROTECTED_DOMAIN list. So how does the PROTECTED_DOMAIN list get updated from a protocol standpoint ? Specifically when there are multiple hubs to serve a domain ? > Again, if you don’t think that is the case, you can choose to implement > with our solution with routing protocol, similar to most vendor (including > Cisco and Juniper) who already do that with IPSec today. That provides > flexibility that an administrator want out of routing protocol. Well in fact, as draft-detienne-01 shows, we can also use IKE (config exchange) but regardless of the prefix transport method, it does not need the domain list contraption to achieve that security level. Now it would be interesting that you specify how a routing protocol works in the context of draft- Also, how do two domains with different mode interoperate ? What happens when a routed spoke talks to a PROTECTED_DOMAIN hub or spoke ? > thanks, > > fred > > >>> >>> thanks, >>> >>> fred >>> _______________________________________________ >>> IPsec mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
