If I understood accurately, author meant to establish mesh BGP sessions, which would allow discovery of each other information. But IMO, this may cause scale issue. AD-VPN is mainly to address a large VPN deployments. As an example, say 2000 end-points are deployed. With this MESH approach, there are (2000 - 1) BGP sessions established in each and every end-point. Generally, end-point gateways are small devices, which may not capable of establishing so many BGP sessions. IMO, this is not scalable approach. Also, even though it may not pass traffic to given end-point, it may have to establish BGP sessions with them.
I do agree with Paul's other security concerns as well. If hacker can establish a tunnel with gateway and get MP-SA, then all end-points are compromised. I also agree, this draft should add more details. Thanks, Praveen On 3/11/13 10:25 AM, "Paul Wouters" <pwout...@redhat.com> wrote: Regarding draft-yamaya-ipsecme-mpsa-00 The draft claims to be about "auto discovery and configuration function". However, I don't actually see any of that in the draft. I have no idea how nodes find out about other nodes they can talk IPsec to. What I do see in the draft is a mechanism for a gateway to relay keying material (nonces!!) for a shared IPsec SA to other nodes after authenticating such nodes. That raises a few questions for me: If we want to accomplish a gateway allowing authenticated parties into a collection of IPsec nodes, why not negotiate separate SA's? There is no real reason to use a single shared IPsec SA session key, and it vastly reduced the security. One conpromised node would reveal the IPsec SA keying material, and with that an attacker could decrypt all the traffic between all the nodes. Plus an attacker could just add a new node to the system (depending on the discovery/permission model that I don't fully understand) Why not distribute some kind of token or PSK between gateway and endpoints, so that two endpoints can then use that to setup the parent SA and do a proper setup of any child SAs with a unique keying material for those nodes? As a bonus, that will keep to a much closer deployment to the existing method. A compromised node might be able to attach itself to the group, but it won't allow the direct compromise of any other node-to-node traffic in the collection. Also this allows each node to reject any proposals for IP address ranges it is unwilling to relay to a particular node. Furthermore, I see no discovery method in the draft that tells a node which other nodes are available via this shared MPSA. How does a node know it can do the MPSA to another node? It seems the draft has no method for asking the gateway about this. Without such a discovery, administrators will still end up having to hardcode node configuration, which is exactly what we are trying to avoid. While the diagrams display there can be gateway-endnode and endnode-endnode traffic using the MPSA, I see no way how the endnode could know this. As a node, I have traffic destined for 192.0.2.1. Should I use an MPSA? I see no correlation between SRC / DST IP addresses and the MPSA. Does this mean any endnode can connect to any other endnode within the group and just make up its own ranges? like 0.0.0.0/0 <-> 0.0.0.0/0 ? That seems like a very weak trust model. Additionally, what if I want my node to be in more then one MPSA group ? Can I have two MPSA's ? How would I know a node is connecting to me is for "MPSA 1" versus "MPSA 2" ? Is there any IKE association between nodes? Or will they just start sending me encrypted ESP for the MPSA? What if someone replays some MPSA encrypted traffic appearing from one node, will my node suddenly stop talking cleartext to it? That seems a weak authentication model. I find the terminology for "rollover time1" (ROLL1) and "rollover time2" (ROLL2) confusing, as it seems to actually be more representative of an "expiration date" and an "activation date". It seems to also overlap with "lifetime" (LIFE). Doubly so as the expiration for ROLL1 has to be related to the start of ROLL2. So we know when to roll, but we still need to connect to the gateway to get the keying material? So why not just limit everything to an expiration time for when the nodes have to contact the gateway again for the new MPSA keying material? The gateway is supopsed to rekey, but that can be difficult with clients behind NAT. Since the gateway informed the clients about the lifetimes, why not let the clients reconnect? So in short: - Distribute authentication information/permission, not encryption material (IKE SA's and traffic selectors are needed) - Devise a mechanism to obtain a list of active nodes or a method to ask the gateway if a certain node is avaialble via MPSA or not. - Reduce the information sent to the minimum required. - Agree on some kind of scope of IP addresses for the MPSA As it stands, I don't really see myself implementing this. There are too many unanswered security concerns, and it does not have enough discovery features in it for my needs. Paul _______________________________________________ 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
