[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compare-jfk-sigma.txt




> From: Dan Harkins <dharkins@tibernian.com>
>
> Yes, it does need to know. To do as you suggest would result in undetectable
> blackholes. In Alice's mind she's going to access 172.21/16 since that's
> in her SPD. In Bob's mind Alice is only going to be allowed to send TCP
> traffic to 172.21.74.113/28 since that's in his. If SPD information is
> not conveyed then Alice's packets that are not TCP to 172.21.74.113/28 will
> be dropped by Bob and there is no way for Bob to inform her of the problem
> or for her to figure it out for herself.

What would would happen, only keys are negotiated, is

1. Alice opens TCP connection to 172.21.74.113 (= Bob)
2. Alice KM contacts 172.21.74.113 negotiates one SA (Alice -> Bob),
   this succeeds, if they have commong algorithms (there is no policy
   checking!)
3. Alice sends IPSECed packets to Bob (172.21.74.113)
4. Bob receives the packet and packet is checked against the policy
   (as defined in rfc-2401).

My starting point is, that if you want secure communications, the
policies must be properly setup, and Alice surely knows that something
is wrong on the Bob's end, if negotiation succeeds, but packets don't
get processes.

Secondly, a difference in selectors does not prevent communication,
for example, if

 Alice: remote = 172.21/16        => use ESP with 3DES
 Bob:   local = 172.21.74.113/28  => use ESP with 3DES

there is no problem, Alice negotiates ESP with 3DES, and Bob's policy
accepts packets to 172.21.74.113/28. Of course, if Alice sends outside
172.21.74.113/28, then Bob's policy does't allow it in (even through
the negotiation of SA succeeds).

If detecting the "black hole" situation is that important, I could be
solved on other simpler ways, than complicating phase II SA
negotiation (for example, if Alice and Bob still have Phase I up, why
not just define some informal Notification message, which Bob sends to
Alice when it drops packets from Alice).
 
> We've had this discussion before (the last one in person at Nokia
> Research Center in Helsinki) and I thought it was resolved. If this
> is more than a religious issue can you explain what problem is
> caused by having SPD information conveyed during SA establishment?

It's not a religious issue, unless you consider having a strong
opinion about what is good architecture a religion (it's sometimes
close to it... :). Why I don't like the old IKE

 - RFC 2401 already dictates policy checking pretty thoroughly as
   mandatory within IPSEC kernel. It's unnecessary to do it in key
   management. (Similary, bundles and tunnel vs. transport is
   unnecessary information for the key negotiation).

 - the "old IKE" could not communicate the "policy" (selectors)
   properly.

 - required symmetric SA's

 - could not share SA's between bundles, for example

     dst = x, protocol = tcp => use AH+SHA1, ESP+DES3
     dst = x, protocol = udp => use AH+SHA1

   without IKE limitations, the AH SA could be shared

 - I'm not expert on judging the old Phase I, but I'm for simplifying
   (reducing) the phase II negotiation to simple unidirectional SA
   negotiation at request of kernel (for example, PFKEYv2 ACQUIRE). No
   policy, nothing else.

In the end, I don't have a power to force this. I have just expressed
my opinion on this list once in a while. I had already resigned to the
reality that IKE is what the IPSEC key management will be, but only
brought my view up once again, as I noticed that there might be
possibility to get it changed.

I will be silent for now, I hope I'm not considered the "Jim
Fleming" of this list.. :-)

-- 
Markku Savela <Markku.Savela@iki.fi>





References: