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.
> > > 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.
> > > 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?
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.
> > > 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.
> > > 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.
> 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.
Ok.
> > > 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.
> > > 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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
