Re: comments on ICPM IPsecTunnelAction and their peers

["Lee Rafalow" <rafalow@xxxxxxxxxxxxxxx>]

It is a bit convoluted, I admit; our intent was to promote orthogonal class
definitions.

1.  When the tunnel action is used in a gateway, there may not be an address
because the peer may be the same as the destination.  In those cases the
packet and the condition identify the peer and the configuration burden is
reduced by using that information.
2.  More generally, the policy action is applicable beyond the specific
endpoint for which it is used.  That is, the device policy is derived from
some more general policy in which the gateway is a free or constrained
variable but not specified; the PDP adds the gateway information for use by
the PEP (device).
3.  The PeerGateway is identified by its identity rather than address
because there are several ways to get the address; the PeerIdentityTable
provides one mechanism.

When we get to implementations of the model, we may want to bias the design
more toward efficiency of the representation.  I hope this helps.  Cheers,
Lee


----- Original Message -----
From: "Ricky Charlet" <rcharlet@xxxxxxxxxxxx>
To: ".MailList - ipsec-policy" <ipsec-policy@xxxxxxxx>
Sent: Thursday, December 28, 2000 6:18 PM
Subject: comments on ICPM IPsecTunnelAction and their peers


> Howdy,
>
> Identifying the peer for an IPsecTunnelAction seems overly complex to
> me. Why not just configure the IP address of the peer right in the
> IPsecTunnelAction as a parameter? What are the reasons behind the
> multiple table references to PeerIdentityTable and IkeIdentity and such?
>
> --
>   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903