Hi Tero, Thanks a lot for your comments. My comments inline with a "VM>" prefix.
On Mon, Sep 10, 2012 at 5:25 AM, Tero Kivinen <[email protected]> wrote: > Paul Hoffman writes: > > 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. > > My comments: > > > 2.2. Gateway-to-Gateway AD VPN Use Case > ... > > The spoke gateways can themselves come up and down, getting different > > IP addresses in the process, making th static configuration > ^^ > Typo. > VM> Perfect. > > > 3.2. Star Topology > ... > > This solution however does not work when the spokes get dynamic IP > > address which the "hub gateways" cannot be configured with. > > I think star topology works fine with dynamic IP addresses. You just > need to make sure that the spokes are the entities which brings up the > link, i.e. immediately when they boot up they put up the IPsec link > and keep it up all the time. There is other identities in the IPsec > world than IP-addresses... > > I would remove the whole sentence. > > VM> I think what we need to talk here is that in case IP address is used as an identifier, we need to make sure that it works even as the IP address changes or we can put it that IP address should not be ever used as identifiers in such cases. > > bandwidth. A single packet in the hub-and-spoke scenario can be > > encrypted and decrypted three times. It would be much preferable if > > In the pure hub-and-spoke model I cannot really see more than two > times, one from the spoke to hub, and second time from the hub to > another spoke. If there is hub to hub links also then it is not pure > hub-and-spoke scenario anymore. I would replace the "three" with > "multiple". I myself really had to read the first paragraph of this > section again to notice that you talk there that this section says > there can be multiple gateways selected as hub gateways. > OK. We can replace with multiple I agree it could even be more than 3 in some cases. > > 4.1. Gateway and Endpoint Requirements > ... > > 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup > > without any configuration changes, even when peer addresses get > > updated every time the device comes up. > > This is unclear for me. Does that mean that anybody can connect to the > gateway and the gateway MUST allow IPsec Tunnels to be setup without > any configuration changes (like adding authentication credentials?). I > do not think so. > > I think this needs to be clarified. Also endpoints do require > configuration changes before they can first time connect to the AD > VPN, for example you need to insert the credentials and most likely > also point at least one gateway for them to fetch rest of > configuration from them. > > If this is just trying to say that already configured devices in the > AD VPN MUST be able to connect to any other configured device in the > AD VPN at any time, even when the IP addresses are not known > beforehand, then I think it should be said differently. > > Anyways I am not sure what this is trying to say. VM> In my view if the first time a hub is connected to a spoke we will need to do some configuration for sure, however as we add other similar spokes (could be based on template), we would require no configuration at the Hub end for each spoke added. Let me know if I am clear here, I can update the document with this. > > This implies that SPD > > entries or other configuration based on peer IP address will need to > > be automatically updated, avoided, or handled in some manner to avoid > > a need to manually update policy whenever an address changes. > > This is much more clear, and I think this most likely means that the > first paragraph was trying to say that already existing AD VPN members > should be able to connect other AD VPN members even when their > IP-addresses are not static. > > Next question is how does the one member know to which address connect > to if also the destination member has changing IP address? And how to > punch holes to NATs that might be between them. > VM> These are the exact questions we need to answer with the protocol solution in my view. > > > 3. Gateways MUST allow tunnel binding, such that applications like > > Routing using the tunnels can work seamlessly without any updates to > > the higher level application configuration i.e. OSPF configuration. > > I have no idea what this requirement means. What is "tunnel binding"? > Where does this requirement come? Which use case drives this? > VM> Do let me know if the mail to Yoav makes it any clearer? > > > 4. In a hub-and-spoke topology, spoke gateways and endpoints MUST > > allow for direct communication with other spoke gateways and > > endpoints. > > Hmm... why are you listing here spokes and endpoints as separate > entries. In the terminology I understood spoke also includes > endpoints? > VM> I agree good point. Will update. > > 5. One spoke MUST NOT be able to impersonate another spoke. > > If spoke does not imply endpoints, then we should say that this also > applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able > to impersonate another spokes or endpoints. > > What about hubs? Are they allowed to impersonate other hubs? I assume > yes, but then next question comes are hubs allowed to impersonate as a > spoke or endpoint? Is there any requirement that when endpoint makes > direct connection to other endpoint it knows that there cannot be any > other parties listening on the link? If there is such requirement then > also the hubs are not allowed to impersonate endpoints, but on the > other hand if we use CA infrastructure, then the CA can always issue > certificate allowing this kind of impersonation. > VM> In my view for the ADVPN case Hubs and spokes have permanent connections. Spokes may have temporary connections with other spokes and in such cases the temporary credentials should not allow any impersonation at all. That was the intent. Let me discuss this with Steve on how to resolve the same. > > 6. Gateways SHOULD allow for easy handoff of sessions in case > > endpoints are roaming, even if they cross policy boundaries. This > > means that TCP session breakage and packet loss should be avoided, > > when possible. > > > > This requirement is driven by use case 2.1. Today's endpoints are > > mobile and transition often between different networks (from 4G to > > WiFi and among various WiFi networks). > > This cannot come from case 2.1, as that is endpoint to endpoint, so > there is no gateway at all there. I would expect this would come from > 2.3 i.e. the endpoint to gateway use case. > > Or does this mean gateways should allow handoff from the > endpoint-gateway-endpoint to direct endpoint-endpoint link without > breaking TCP sessions? > VM> The intent was the first paragraph you mention, but I do not see any reason we should now allow for a direct connectivity either as you mention in the second paragraph. > > 8. Gateways and endpoints MUST be able to work when they are behind > > NAT boxes. However, it is especially difficult to handle cases where > > gateways are behind NATs and where two endpoints are both behind > > separate NATs. In those cases, workarounds MAY be used such as port > > forwarding by the NAT or detecting when two spokes are behind > > uncooperative NATs and using a hub in that case. > > > > This requirement is driven by use cases 2.1 and 2.2. Endpoints are > > often behind NATs and gateways sometimes are. IPsec should continue > > to work seamlessly regardless, using AD VPN techniques whenever > > possible and providing graceful fallback to hub and spoke techniques > > as needed. > > Does this also include discovery of the addresses? How about if we > have two endpoints talking to each other and one of the nat boxes is > restarted and one peers IP-address changes, and as the NATs are > restricted nats, which means they cannot connect to each other at all > after that without the help of the 3rd party. Also the 3rd party > cannot connect to either one of them, thus the recover must then start > from the endpoints so both of them connect to this 3rd party (hub) to > recover from the situation. > VM> I think the idea here is that spokes being behind NAT's, and the solution should allow for a tunnel setup between them. There can be external factors however like firewall/ NAT etc which may have cause issues and need to be dealt with seperately. > > > 9. Changes such as establishing a new IPsec SA SHOULD be reportable > > and manageable. However, creating a MIB or other management > > technique is not within scope for this effort. > > > > This requirement is driven by manageability concerns for all the use > > cases, especially use case 2.2. As IPsec networks become more > > dynamic, management tools become more essential. > > I would rule configuration MIB out of the scope, but I would actually > think it would be good idea to make reporting and statistics MIB. We > really need one in the IPsec, and this is effort I think we should > take here in ipsecme also for normal IPsec devices. > > VM> I agree with what Yoav said on this. I agree we should allow for logging/ tracking dynamic changes. Let me discuss with Steve on whether we should add having a MIB as a requirement for the same. > I am sure we are still missing some requirements, but thats my > comments for the existing requirements. I need to think bit more what > other requirements we might have. > VM> I would love to hear such requirements. Thanks, Vishwas > -- > [email protected] >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
