[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements
From: Tero Kivinen <kivinen () iki ! fi>
Date: 2012-09-25 13:14:32
Message-ID: 20577.44600.597261.533593 () fireball ! kivinen ! iki ! fi
[Download RAW message or body]
Vishwas Manral writes:
> > 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.
The text in the document claiming that Star topology does not work
when the spokes get dynamic IP address is still wrong. As I explained
in my examples there is nothing in the current protocol specifications
which makes them "not work" or "cannot be configured with".
> > 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).
>
> 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.
As we are trying to get rid of the rigid star topology (it was listed
in the "Inadequacy of Existing Solutions"), I think we need more
relaxed definition for the spoke. If our star topology is no longer
strict rigid star, but more like dynamic mesh kind of thing, then
talking about what spokes needs to do and what they do not need to do,
gets very confusing.
> > 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.
Then we might want to add specific requirements for each class of
devices.
> > > > > 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?
As you said it yourself and appended with the rest of the old text:
Gateways MUST be able to run routing protocol over the IPsec
tunnels, even as they change their end point IP addresses.
This means that applications like Routing using the tunnels
can work seamlessly without any updates to the higher level
configuration i.e. OSPF configuraiton.
I did understand that end part of it, but I did not know whether there
was something hidden meaning with the "tunnel binding" part that I did
not get. I mean if there is some other requirements coming from the
"tunnel binding" part then we should explictly say it out here, not
trust that someone who reads the "tunnel binding" knows what those
requirements are.
> > > > > 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.
That is fine if we think that spoke-to-hub connections are permanent
and do not change. I think there would be uses for where spoke
realizes that it would be better served by an another hub than the one
which is primarly connected to, and it could connect to another hub in
addition than connecting directly to the all the spokes behind that
hub.
If you feel there is no use case, then we can leave it out.
> > > > > 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.
So you mean that when we have endpoint-gateway-endpoint connection,
and for some reason the gateway wants to hand that connection to so
that connection will be endpoint-another gateway-endpoint?
> 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.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic