Re: Issue# 2-Gateway Discovery

[Yaron Sheffer <yaron.sheffer@xxxxxxxxxxxx>]

Hi Matthew,

your note below hints at another way to look at gateway/policy discovery.

I can see four major problems with path-based policy discovery:

1. Routing: the assumption that you can just send packets into another
security domain is typically incorrect. People use private (non-routable)
addresses as well as private DNS servers, exactly to defeat this
possibility. So tunneling is part of your addressing (routing), not just
part of your security.

2. Resiliency: routing can change at any time. But path negotiation fixes
it for the duration of the flow.

3. Scalability: the end-point (or end-points) need to deal with the
complexity of a long path with many gateways and many policies that need
to be resolved.

4. Security: I think it is not realistic to assume that people will let
policy discovery packets worm their way into their networks. Especially
in the cases when you have nested security domains (and nested gateways),
people are least likely to allow alien packets in.

Unfortunately I don't have a solution to offer. But a possible direction
would be a hierarchy of policy servers, where each is familiar with its
own domain and its local policies, and can locate other servers and
negotiate with them. Such negotiation can result in temporary agreements
to tunnel a certain flow in a certain way. A high-level server may need
to consult with a subordinate server when creating an agreement.

Thanks,
    Yaron

Matthew Condell wrote:

>
> >    4-During the course of discovery, who should
> >      learn the topology? The initiator? All gateways
> >      the discovery message traverses? Border gateways?
>
> 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.
>

begin:vcard 
n:Sheffer;Yaron
tel;cell:+972-51-628922
tel;work:+972-3-765-8922
x-mozilla-html:TRUE
url:www.radguard.com
org:Radguard
adr:;;Atidim Technology Park, Bdg #4;Tel Aviv;;61581;Israel
version:2.1
email;internet:yaron.sheffer@xxxxxxxxxxxx
title:Group Leader, Technologies
fn:Yaron Sheffer
end:vcard