Hi Tero/ Yoav, Thanks for your great comments. We are discussing this internally and will get back to you in a few days.
Thanks, Vishwas 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. > > > 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. > > > 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. > > > 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. > > > 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. > > > 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? > > > 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? > > > 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. > > > 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? > > > 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. > > > 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. > > 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. > -- > [email protected] > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
