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

Re: Out of Sync Security Policies - Design Flaw

I am in agreement that you cannot have out of sync policies with the current
RFCs.

You should not fail the IPsec SA negotiation due  to a wildcard mismatch. The
intention for the wildcards is that one side does not care about the selector.
Using this logic, if the initiator gives a range of IP addresses, then the
responder must also have the same range of addresses in its security policy.

I believe that a third Id payload would be required:

- Id payload for Initiator's security policy selectors
- Id payload for Responder's security policy selectors
- Id payload for Initiator's packet selectors

With the above, each side could accurately put the most granular selectors in
its SA (indirect negotiation of policy selectors).

Kim

 >         I'm not 100% sure because I had problems with this as well, however,
 > I'd say that the first IKE negotiation I wrong and should fail because
 > selectors don't match. If the INITIATOR proposes ANY protocol then the
 > RESPONDER must have ANY in the policy as well. Otherwise you have funny
 > situations like yours.
 >
 > Toni
 >
 >
 > -----Original Message-----
 > From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com]
 > Sent: 03. November 2000 17:57
 > To: ipsec
 > Subject: Out of Sync Security Policies
 >
 > We are having a problem with out of sync security policies (sp) and we
 > would like to know what other implementations are doing to address
 > this problem. It is possible that we are simply missing something from
 > the RFC.
 >
 > setup:
 >
 > Gateway A                                                      Gateway B
 >
 > Initiator --------------------- Responder
 >
 > sp/1
 > sp/1
 > ip addresses: 10.1.1.0                                     ip addresses:
 > 10.1.1.0
 > protocol: any                                                  protocol:
 > tcp
 >
 > sp/2
 >
 > ip addresses: 10.1.1.0
 >
 > protocol: icmp
 >
 > Assumptions:
 >
 > 1. all data traffic is flowing from Gateway A to Gateway B.
 >
 > 2. The selectors in a negotiated SA use the value from the
 > corresponding security policy (option b from section 4.4.1, RFC 2401).
 >
 > 3. there are no SAs initially setup.
 >
 > 4. all security policies have the action: protect.
 >
 > Now, if we generate a tcp packet, an SA will be negotiated between A's
 > sp/1 and B's sp/1. The selectors in A's SA will contain "any" as a
 > protocol (assumption 2).
 >
 > If we then send an ICMP packet, the ICMP packet will see that an SA
 > exists according to the sp and SA selectors and a protected packet
 > will be sent to B. B will verify/remove the protection and then verify
 > that the selectors match. Since B's SA selectors contain the protocol
 > "tcp" (assumption 2), the packet will be discarded as the protocol is
 > "icmp".
 > Therefore, it is impossible to send ICMP traffic without clearing the
 > previous
 > SA or having matching sp on both sides.
 >
 > How do we get ICMP traffic through in such a setup?
 >
 > We must be missing the obvious.
 >
 > I must apologize if this has been discussed in past threads, but I
 > could not find any references to this problem.
 >
 > Kim Edwards
Follow-Ups: References: