Re: Issue# 2-Gateway Discovery

[Matthew Condell <mcondell@xxxxxxx>]

> [AR] Your example is about tunneling policies. I dont have a problem
> with that but is this the whole purpose of discovery to figure out how
> tunnels align? Or discovery gateways to provide a mechanism for
> applications to interact with firewalls and inject pinholes to enable
> such applications to run with less manual provisioning? I think that
> gateway discovery has to do with tunneling policies, filtering policies
> and network policies.

The purpose of discovery is so we know which gateways exist so we can
resolve policies for IPsec and IKE.  

Injecting pinholes in firewalls sounds like trying to change a firewall's
policy to me.  We shouldn't be changing anyone's policy.  We just want
to find the common elements of the policies between the communicating
entities so that they can communicate if the existing policies will
already allow it.  

> > We need to discover who will be participating in the policy
> > distribution and resolution process.  So, likely it will be
> > the policy server, unless the architecture dramatically changes.
> > Credentials will be needed.  Whether or not they are retrieved
> > during the discovery process is proabalby debatable
> 
> [AR] Servers? How? servers are not in the signaling path of
> flow. Gateways are! So for this to work the gateways have to
> run in the proxy mode for the servers. Or extend DNS to allow
> for server discovery! Either way, if I have the IP address of
> a gateway, then I know that I can run whatever protocols we
> come up with to resolve the policy issues but do I have that
> to start with? and if I do, what else do I need to discover?

Gateways can redirect the discovery protocol packet to the
server.  This solution has worked fine for SPP. Since policy 
resolution happens at the server (which may or may not also be 
the gateway), server discovery is more important for policy 
resolution.  

> > I don't think each policy server should need to know more than the
> > end-points of the communication and the policy server (or gateway)
> > on either side of it.
> 
> [AR] If we dont need the topology, then why are discovering
> gateways? The problem is to know the topology so the server
> would be able to have a sound policy! It is not always the
> case that you have two gateways at the endpoints of communication.
> You might have a network architecture where there are 3 or 4
> gateways along the path to challenge intruders. So having found
> the first gateway, does not mean you wont be challenged by
> the next one and you would have to go through the same
> process of discovery again!

We should be discovering policy servers, not gateways.
Any relevent topology information is contained in the policies.
As gateway 1, I don't need to know gateway 3 exists unless I will 
see a communication that has gateway 3 as a tunnel endpoint.  
The existence of that tunnel will be contained in the policy.

> > >    5-How can authentication and privacy be utilized
> > >      to ensure that the topology information is read
> > >      only by the intended gateways?
> >
> > Depends a lot on the answer to 4...
> 
> [AR] While authentication and privacy may be waived
> in certain circumstances it is a requirement in general
> and whatever solution we come up with should resolve
> this issue!

I agree.  I was not saying it was not a requirement, but how
it gets used depends on the solutions to discovery and resolution
we use.  The solutions will look different if all is done at 
once or if it is done in multiple phases.

> > >    8-Can/should policy discovery be part of the
> > >      gateway discovery?
> >
> > Can - definitely.  SPP proves that.
> > Should - I believe so.  See 9.
> 
> [AR] I disagree. The problem is policy protection! In some
> circumstances you may not require protection because
> dont care or other mechanisms already exist. But if discovery
> is to stand alone which is most probably the way to go,
> protection is something that is going to be mandatory.
> During the gateway discovery phase, you have to give
> up something to learn the topology. But I am not willing to
> risk my policy requests being jeopardized because they
> must be part of the gateway discovery phase!

Confidentiality can still be provided for policies when combining
server and policy discovery.  Policy does not have to be distributed
on a policy request where confidentiality services cannot be provided.  
Policy only needs to be distributed on the reply to that request when
confidentiality services _can_ be provided.  However, there is a trade 
off of what can be resolved, since the resolution will be done with
partial information.  

It should be up to the working group to decide whether it is better
to split server and policy discovery or to allow the user to 
choose between full and partial resolution.  Both have efficiency
and confidentiality tradeoffs, but over different sets of data.

Matt