Re: some questions about draft-ietf-ipsp-ipsec-conf-mib-06.txt

Hi,
Sorry for the untimely response, responses inline below.

>>>>> "Norbert" == Norbert Reinartz <Reinartz> writes:

    Norbert> There are a few questions about the 'IPsec Policy
    Norbert> Configuration MIB':

    Norbert> How to configure preconfigured SAs?  The transformations
    Norbert> of ipsec tunnels are described within 2 SAs, where each
    Norbert> SA describes the transformation of incoming or outgoing
    Norbert> traffic.  Using the 'IPsec Policy Configuration MIB', we
    Norbert> have to configure two ipspSaPreconfiguredActionEntries.
    Norbert> In which way should these two entries be joined with the
    Norbert> correspondent filter(s)?

    Norbert> There are two ways, I think:
    Norbert> 1. Separate configuration for each direction. Each
    Norbert>    direction is configured
    Norbert> with a separate ipspIpHeaderFilterEntry,
    Norbert> ipspRuleDefinitionEntry and ipspGroupContentsEntry. One
    Norbert> ipHeaderFilter is configured for outgoing traffic (filter
    Norbert> describes unprotected data) and one filter for incoming
    Norbert> traffic (filter describes protected data,
    Norbert> i.e. considering AH or ESP protocol).

This is the most straight forward way to do it.

    Norbert> 2. The tunnel is configured with one rule and one
    Norbert>    filter. The two
    Norbert> ipspSaPreconfiguredActionEntries are joined with the
    Norbert> ipspRuleDefinitionEntry using a ipspCompoundActionEntry
    Norbert> and two ipspSubactionsEntries. The
    Norbert> ipspIpHeaderFilterEntry is used for matching outgoing
    Norbert> traffic. The filter for incoming traffic isn't
    Norbert> configured. It is created implicit by the application
    Norbert> (using the information which protocol transformation is
    Norbert> used for incoming traffic, ..).

In practice, an implementation could do this, but it doesn't work
theoretically. By that I mean, following the information model, the
IPsec rules are checked first for incoming packets, before the SADB is
examined. Without an associated filter, the incoming packet would
never match the IPsec rules and be connected to the preconf. SA.

More to the point, an explicit traffic filter should exist for
incoming preconfig. SA's so that any traffic coming through the SA can
be checked to make sure that it is the appropriate traffic for that SA
(beyond matching SPI and AH/ESP info.).

    Norbert> Can someone describe, how the configuration of
    Norbert> preconfigured SAs should be done.

    Norbert> One more question: I'm missing something like a parameter
    Norbert> for the direction of filters. There is no way to
    Norbert> configure filters for outgoing, incoming or both
    Norbert> directions of traffic. Is there a general meaning of the
    Norbert> direction, e.g. both?

In fact, there has been some discussion among the draft writers
regarding adding direction information into filters. If it should be
added and exactly how it should be added haven't been decided yet. My
best guess at the moment is that it will be added in the form of an
additional direction filter. Input is welcome.

    Norbert> Whats the state of the 'IPsec Policy Configuration MIB',
    Norbert> is work going on? I couldn't read anything new about the
    Norbert> draft for long time.

As mentioned above, some work is going on. Although at this point,
changes should stay at minimum.



-- 
Michael Baer
[email protected]
sparta