Hi Tero, Thanks for the great comments. Your main comments seem to be around clarifying the terminology and you have very thoughtfully expanded the definitions. I agree with most of it, just one question in the comments regarding the same.
We seem to be on the same page here. Please see inline: On Mon, Sep 17, 2012 at 4:50 AM, Tero Kivinen <[email protected]> wrote: > Vishwas Manral writes: > > > > 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. > > > > > 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. > > There is quite big difference "cannot be configured with" and "cannot > use IP-addresses as identifiers". And I agree IP addresses should not > be used as identifiers in these cases, but that actually DOES NOT > prevent it working. The ID is just identifier that can be used for > policy lookup, and the RFC5996 says: > > When using the > ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 > does not require this address to match the address in the IP header > of IKEv2 packets, or anything in the TSi/TSr payloads. The contents > of IDi/IDr are used purely to fetch the policy and authentication > data related to the other party. > > So even when the spokes have dynamic IP addresses they can use > whatever ID_IPV4_ADDR/ID_IPV6_ADDR they like to identify themselves to > the other end. For example they could always use their internal > IP-address, i.e. something like 10.22.8.1 when this device is > responsible for the traffic to 10.22.8.0-10.22.12.255, or it could use > IP address of 0.0.0.1 as this is first gateway and second gateway > could use 0.0.0.2 etc... Both of those are completely legal in RFC5996 > sense, but neither of them might not be good idea in practice. > Perfect. Though we are not solving the problems yet, I guess those are great inputs for the solution. > > > > > 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. > > I would expect that adding new spoke to hub only requires initial > configuration in the newly added spoke, and MAY require configuration > changes in the hub where the spoke is connected to, but SHOULD NOT > require configuration changes to the other hubs than the one where the > spoke was connected to, and MUST NOT require configuration changes in > other spokes. > > Or something like that for the adding new spoke to the AD VPN. To add > new hub it might require more changes, i.e. adding new hub to the AD > VPN do require initial configuration in the newly added hub, and MAY > also require configuration changes to the other hubs, and MAY also > require configuration changes to the spokes connecting to this new > hub, but SHOULD NOT require any configuration changes to the spokes > connected to the other hubs. > > Actually the current definition in the section 1.1 says: > > > Hub - The central point in a star topology, generally implemented in > a gateway. > > meaning, there can be only one hub. And I just wonder how can hub not > be a gateway? I think it must always be a gateway, i.e. it always > protect traffic flowing through the device, otherwise it is not hub > it is server (and outside the scope of the AD VPN). > > Perhaps we should expand this and define several different types of > devices: > > Hubs - The central point in a star topology, or one of the central > points in the mesh style VPN, i.e. gateway where multiple > other hubs or spokes connect to. The hubs usually forward > traffic coming from encrypted links to other encrypted > links, i.e. there is no devices connected to it in clear. > > Spoke - The edge devices in the a star topology, or gateway which > forwards traffic from multiple cleartext devices to other > hubs or spokes, and some of those other devices are > connected to it in clear (i.e. it encrypt data coming from > cleartext device and forwards it to the AD VPN). > > Endpoint device - A device that implements IPsec for its own > traffic, but does not act as a gateway. > > Cleartext device - A device that does rely on the spokes to protect > its traffic. Cleartext device might implement > IPsec, but does not use it in currect setup. > > I.e. we should define that there are cleartext devices which talk in > clear to the spokes, which encrypt the traffic and forward it either > to hubs, other spokes, or endpoints, these are devices like those in > the branch office network, which use spokes as their encryption > providers. > > Then there is endpoint devices which take care of their own > encryption, and connect directly to the spokes, hubs and other > endpoints, but do not connect directly to the devices behind spokes. > Note that endpoint can move to be cleartext device if it moves to > network that is already protected by spoke. In the same way cleartext > device can move to be endpoint device if it moves out from the network > protected by the spoke. > > Those two are the end user devices, i.e. those devices where the user > itself is. The spokes and hubs are just network devices forwarding > traffic. > > Those definations might make things a bit more clear, especially when > we are talking about the required configuration changes. I.e. we do > not want to have any changes to any other Endpoint or cleartext > devices than what we are modifying now (adding, removing), we may have > changes to the neigbour spokes and hubs, but we should not have any > changes to spokes, or hubs further away. > Great inputs will update the definitions in the document based on the inputs here. >From our perspective the difference in terminology (between what you have said and what the draft says) seems to be the spoke. In our definition a Spoke is an edge device in the star topology which can be an end-point or a gateway. Other definitions look good to me. > > > > > 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. > > > > > These are the exact questions we need to answer with the protocol > > solution in my view. > > I meant to say is that requirement that it should work in such setup > too, or do we just say that there is no such requirement, and on end > of the connection must have static ip-address. > > Also talking about NATs which classes can be behind NAT? > > I assume we do require that endpoint devices MUST be able to be behind > NAT. Cleartext devices does not matter, as they do not do IPsec > themselves. Do we require that spokes also can be behind NATs? What > about hubs? > Yes the aim is ADVPN end points can be behind NAT's. I agree a hub may not require to be behind NAT, but if two spokes communicate both of them can be behind NAT's. > > I would expect that spokes can be behind NAT, so we should probably > require that, but I am not sure if the hubs themselves will ever be > behind NAT, and it would make things much easier if we say that there > is no requirement to support setups where hubs are behind NATs. This > would solve the problem that when new spoke is added and it is trying > to fetch to configuration, it knows what IP address to use as the > IP-address of the hub can be configured to it... If all the hubs have > dynamic IP-addresses things get really complex... > > > > > 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? > > > > > Do let me know if the mail to Yoav makes it any clearer? > > Not really. I still do not understand what you mean by tunnel binding. > The requirement is that in an Enterprise, we may want the branch addresses to be propagated to the Hub, and run routing protocol over the IPsec tunnels, even as they change their end point IP addresses. If this is not clear, would it be possible to expand the question? > > > > > 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? > > > > > I agree good point. Will update. > > Actually I think it would be easier if we make bigger changes to the > terminology, like we I proposed earlier. I.e. define roles of hub and > spokes better, and not tie them to the star-topology, like we > currently do. And in my version the spokes does not include endpoints, > as endpoints do not have any cleartext devices behind them. > Ok, let me look at the complete document for clarity. > > > > > 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. > > > > > > > In my view for the ADVPN case Hubs and spokes have permanent > > connections. > > This is not specified anywhere. If such requirement exists, we need to > list it as requirement. I for example do not agree on that. I think > hub-to-hub connections should be permanent, but hub-to-spoke > connections might not be permanent, as one spoke might decide it is > forwarding stuff so much to some other hub, that it might be better to > connect directly to that hub, and only use local hub for more local > traffic. > I am trying to impose the typical enterprise connectivity scenario here - where the hubs and spokes have permanent connections, while the spoke to spoke connections come up and go down. I can add your use case too to the document, but I do not see in cases I know of. > > > > > > > 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? > > > > > 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. > > I am lost now. I think this requirement needs to be specified more > clearly, so I can understand what is mean by it. > > The intent of the document was to allow for handoff between gateways for endpoint-gateway-endpoint connectivity. What I was saying was, we can look at the use case you mention of handing off a connection from endpoint-gateway-endpoint to endpoint-to-endpoint. > > > > 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. > > > > > 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. > > The original requirement talked about gateways and endpoints, and > gateways also includes hubs. I think we really need to define those > roles more clearly. > Got the point of clarifying the definitions further and will do so. Thanks, Vishwas > -- > [email protected] >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
