[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed IPSEC changes/extensions
Steve, thank you for the quick response. I put my comments after your text.
Regards, Pau-Chen
In message <v02130510ae9cfdd69597@[128.89.30.7]> Stephen Kent wrote :
>
> Pau-Chen,
>
> I thought some more about the question of where the info shoukld
> live that defines the set of IP datagrams that map into a single SA. My
> initial response to your message was that I may have put this data in the
> wrong place, by listing it in the per-SA MIB. However, the right answer
> may be that it lives in two places: the MIB entry I described and a
> separate database that defines policy. My thinking is that when we receive
> an outbound packet we have to do a table lookup to determine if any
> existing SA is appropriate for carrying this packet, or if a new SA must be
> established. The first check is made against a database of existing SAs,
> while the second refers to a separate database that expresses the static
> policy of what sort of SAs should be created. Thus it would seem
> reasonable to make the first check against a databse that showed what set
> of selectors were already in use for outbound traffic. In that context,
> your suggestion about explicitly listing the set of IP addresses (ports,
> etc.) bound to a single SA makes sense and may be better than the wildcard
> address approach I described (depending on the search details). If an
> explicit address list were used, then a new packet that could be carried on
> an existing bulk SA would not be immediately recognizzed, but when it was
> referred to the SA policy the wildcard match would indicate that the packet
> could be muxed with other traffic. Then one would have to make a different
> check to see if such an SA already exists and add this outboud address to
> the explicit list bound to that SA. These processing details are below the
> level one would want in the spec, but having this sort of model to discuss
> may help resolve the questions you raised.
>
> Steve
>
>
My model is the policy will tell which (kind of) SA to use. So the 1st search
is done through the policy to determine which (knid of) SA, if any, should be
used. Then we go through the existing SA's to see if an SA meeting the policy
requirements exists. If one exists, then we can just uses it. If not, one can
be created. The policy will carry the notions of wildcard, address range,
protocols, port ranges, etc.(God knows what.). (Of course, a simple mechanism
is invented to define a "kind of" SA.)
The intention here is to decouple the policy from the SA. I consider policy is
very subjective and can, at least in theory, appears in many different forms;
so it is not standarized (and IMHO, it should not be.). But SA should be simple,
precise and standarized (at least in conceptual level), so SA can be negotiated
by standard KMP.
At present, the above concept has been implemented in IBM IPSEC code (including
a key refreshment protocol (not ISAKMP)) and placed in IBM firewall.
It seems to work pretty well.
I do think, however, it is useful for an end of an SA to advise the other end
how it wishes the SA to be used. This may be done by communicating
protocol, port (ranges) in the KMP in addition to address (ranges).
Pau-Chen