[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gateway Discovery-Architecture Proposal
Matt,
See comments below.
Matthew Condell wrote:
>
> Abdallah,
>
> Thank you for taking the time to sketch out several examples.
> However, I think you have failed to address the concerns I
> expressed.
>
> First, your examples seem to have a couple of implied assumptions:
> 1) SG1 and SG4 both have policies that require an ESP tunnel between
> them.
> 2) When you say a SG has a "No ESP" policy, it means that the SG will
> not allow an ESP protected message to pass through it, but its
> policy, and the policies of SG1 and SG4 allow the alternative
> of ending the tunnels at the SG.
[AR] 2) The examples are to illustrate the possibilities and each
SG is to make its own decision whether to proceed or not. If it
is to go ahead then the examples show how it is going to be.
Otherwise, terminate the process. At times, it might not be possible.
As for 1) It is the confidentiality policy that dictate how
to proceed. For example, during the discovery it could be
indicated that confidentiality is to be provided using ESP
tunnel or not required. Profiles should be the venue of telling
gateways the minimum requirements for the next phase. That is why
I indicated in the examples that IKE can be optional if needed.
> When I have been referring to a SG having a No ESP policy, I've meant
> that the policy means no ESP may pass through and there are no
> alternative solutions so the communication must be denied.
[AR] I agree. The examples shows the complete steps if things
proceed with current assumptions but a gateway can terminate
whenever its requirements are not met.
> With those assumptions down, I think I can explain a case that I
> am concerned about better.
>
> This is similar to your Case 1.B:
> >Case 1: SG1 performs Discovery/IKE/Resolution and has no policy
> > restrictions from SG2.
> > B- SG4 performs Discovery/Resolution with SG1 but SG3 has
> > "NO ESP" policy
>
> However, SG1 does *not* require an ESP tunnel with SG4 (but doesn't
> prohibit one) and SG4 does require the tunnel. No ESP is interpreted
> as I have meant it to simplify the policies.
>
> At step 1.B.8 in your example, the IKE negotiation stops at SG3,
> because SG3's policy prohibits an ESP tunnel, if I understand the
> example correctly.
>
> However, in my example, no policy will have yet been resolved that
> will indicate to SG3 that an ESP tunnel is being requested, since SG1
> does not require an ESP tunnel, so I presume it would continue on as
> step 1.A.8 and 1.A.9 does. At 1.A.9, the resolution protocol will
> discover that there will be an ESP tunnel from SG1 to SG4, however
> SG3 can no longer participate in the policy resolution to complain
> about the tunnel.
[AR] Not exactly. What SG3 needs to do is to publish its policies to
SG1 and SG4 to make sure that they know the rules of the game. In
step 1.A.6, SG1 will learn SG3 requirements. As for SG4, SG3 can
in the middle of 1.A.6 engage in case 2.B.b making sure SG4 understands
the requirements of SG3. In this scenario, SG3 is making SG1 and SG4
aware of what they need to do in order for their communications to
proceed. Also, SG3 would need to inspect the profiles in step 1.A.7
to make sure that eps tunnel is not going to take place in step 1.A.8,
otherwise, it will send failure type of message to both parties
indicating failure of communication and enforcing its own policy.
The fact of the matter, someone has to give up some of their security
requirements if there is such a conflict, or else no resolution will
take place. SG1 and SG4 can decide not to use eps tunnels or
use a different interface if possible.
The resolution process should involve the two ends of communication.
Intermediate gateways should not interfere on the decision process
like changing the policies. Only the end points should be the ones
that make policy decisions. The reasoning for eps tunnels is to
enforce this concept, however, it is up the endpoints if they give
this up and resolve their policies on the clear.
> Here's a similar example, that avoids "No ESP" policies:
>
> Using the same SG1-4:
>
> SG1, SG4 both require an ESP tunnel between them.
> SG3 requires an ESP tunnel with SG2
> (SG2 does not prohibit it)
>
> Steps 1.A.1 - 1.A.6 from your examples would apply here, I believe.
> However, in 1.A.6, the policy resolution between SG1 and SG3 would be
> hidden from SG2, so SG2 would not have a say in the policy of a tunnel
> between it and SG3. (Which might be okay if SG2 does not object to
> the tunnel, but what if it does?)
[AR] Interesting point. Since SG3 has a policy then it is going
to enforce it during step 1.A.4. SG3 receives a discovery message,
establishes an esp tunnel with SG2, then use it to reply to the
discovery of SG1. From now on, any communications between the two
will be encapsulated in that tunnel. I will add a new example for
this case. So when step 1.A.6, the tunnel between SG1 and SG3 will
be encapsulated in another tunnel, SG2-SG3.
If SG2 objects to the tunnel, this would be a similar case to
the previous comment about SG3.
Remember sometimes it is not possible to communicate due to some
stringent policy conditions. In such a case a deadlock can not
be averted.
> Hope this clarifies my concerns,
>
> Matt
[AR] By the way, these cases require a state diagram
identifying the action for each state indicating which
policies to enforce with possible exceptions when
they occur.
Abdallah