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

Re: inbound policy verification

> 
> [I just joined the ipsec list. I've skimmed the minutes from the August IETF
> and the last month's archives. I'm reading the July '98 security
> architecture draft. I understand this draft was just approved by the IESG.
> I'm working on an implementation: http://research.microsoft.com/msripv6. My
> questions stem from a recent group discussion with Aaron Griggs, Maryann
> Maher, Allison Mankin, and Brian Zill.]
> 
> 
> I don't understand an aspect of the inbound processing specified in section
> 5.2.1 of the security architecture spec. As specified, the processing would
> seem to create a security problem.
> 
> As I understand it, the basic idea is that a) the headers are processed and
> list of SAs used are collected, then b) the selectors from the packet are
> used to locate a security policy in the inbound SPD/SAD, then c) check that
> the SAs that were used match the SAs that are specified by the policy.
> 
> The part I don't understand is the provision that if the SAs don't match,
> then the implementation should continue searching the inbound SPD until it
> either finds a policy that accepts the packet, or it's checked all the
> policies in the inbound SPD.
> 
> This would seem to make it impossible to enforce a more-restrictive policy
> in the inbound SPD when there is also a more general policy.

Where do you find this provision? It does seem inconsistent if true.
I looked up section 5.2.1. Step 2, which refers to inbound policy 
enforcement. In particular, the following statement seems to contradict
the provision you refer to. 

     In general, a packet's source address MUST match the SA selector value.

In the above statement, the author assumes the packet is subject to 
successful authorization and decryption per receiving SA terms, prior to 
policy verification. Also, the packet above refers to the inner packet, 
if the received packet is tunnelled. 

> 
> For example, suppose I'm a host H1 and I expect to receive packets from a
> network N2, but there's a particular host H2 in N2 for which I have
> different security requirements. So I create two policies in my inbound SPD
> - first one with source address selector H2, and the second one with source
> address selector N2 (an address prefix or range). The first policy results
> in a SAD entry with security association SA1, and the second results in a
> SAD entry with security association SA2.
> 
> Now suppose I receive a packet from H2 with the "wrong" security headers. I
> process the packet and discover SA2 from the destination
> address/SPI/protocol triple and do the required authentication/decryption.
> Now I search the SPD. The packet's selectors match the first policy but the
> wrong SA was used to receive the packet. I want to reject this packet.
> 

Unfortunately, I believe, what you describe is a real possibility, unless 
there is a strict enforcement of policy ordering/priority during IKE 
negotiation.  The example you describe should be a good reference to use 
in IPsecond as we pursue policy enforcement.

For brevity, let us assume SA1 and SA2 you describe are bi-directional.
I believe, the following policy ordering on H1 and H2 could cause the 
above mishap to happen on a regular basis with the current approach.

Policy ordering on H1:
---------------------
1. Permit all IP traffic from H1 to H2 using SA1
2. Permit all IP traffic from H1 to N2 using SA2

Policy ordering on H2:
---------------------
1. Permit all IP traffic from N2 to H1 using SA2
2. Permit all IP traffic from H2 to H1 using SA1

H1 would use SA1 to send packes to H2, whereas H2 would use SA2 to
packets to H1.

> However this provision says I should continue searching the inbound SPD. I
> find the second policy; the packet's selectors match it also. SA2 is the
> right SA for this policy, so I accept the packet.
> 
> Surely this can't be right? What am I missing?
> 
It does seem inconsistent if true.

> Thanks,
> Rich
> 

cheers,
suresh
References: