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

RE: SA Rules


At 15:35 6/02/2002 -0500, Casey Carr wrote:
Eric,

1)  Do you agree with the Jamie's response to the changes I've requested
concerning the associations between policy group and SA rule?  Will this
change be incorporated in the -05 document?

Yes, all authors agreed on your proposal (thanks for catching it)

2) There was agreement last week that the IPSec policy model does not
support address ranges in for filter entries.  Will there be a fix to the
model to support this feature?

Actually, the IPHeadersFilter class is coming from PCIMe and as far as I know PCIMe is currently extending this class.

-eric


Casey

-----Original Message-----
From: Eric Vyncke [mailto:evyncke@xxxxxxxxx]
Sent: Wednesday, February 06, 2002 3:26 PM
To: Casey Carr
Cc: Jason, Jamie; IPSec Policy WG
Subject: RE: SA Rules


Yes, the -05 is mostly complete (basically nothing completely new, just
minor fixed + clarifications)

-eric

At 08:02 6/02/2002 -0500, Casey Carr wrote:

>Will there be another rev to the document prior to last call?
>
>-----Original Message-----
>From: owner-ipsec-policy@xxxxxxxxxxxxx
>[mailto:owner-ipsec-policy@xxxxxxxxxxxxx]On Behalf Of Jason, Jamie
>Sent: Tuesday, February 05, 2002 4:21 PM
>To: 'Casey Carr'; IPSec Policy WG
>Subject: RE: SA Rules
>
>
>
>Casey,
>
>I think that the aggregations you point out are vestiges of the original
>model.  There is no reason why these two cannot be combined into one
>aggregation.
>
>Good catch.
>
>Jamie
>
> > -----Original Message-----
> > From: Casey Carr [mailto:kcarr@xxxxxxxxx]
> > Sent: Friday, February 01, 2002 11:32 AM
> > To: IPSec Policy WG
> > Subject: SA Rules
> >
> >
> >
> > After implementing the IPSec policy model I have some a small
> > gripe.  First I would like to thank those who put the time
> > and effort into this model.  It has proved very useful for
> > our IPSec gateway policy manager implementation.
> >
> > The issue I have is with RuleForIPSecNegotiation and
> > RuleForIKENegotiation. Can someone explain to why there is
> > not a direct association between an SARule and
> > IPSecPolicyGroup?  This association would probably have the
> > name SARuleInPolicyGroup.
> >
> > Wouldn't it be cleaner to be able to prioritize a single
> > collection of rules instead of having to prioritize on set of
> > IKERule objects and one set of IPSecRule objects?  Since
> > these associations each have their own priorities, I have to
> > deal with the possibility that an IKERule and an IPSecRule in
> > the same policy group can have the same priority.
> >
> > This complexity seems to been eliminated from the rest of the
> > model.  For instance there is not an association
> > IKEActionInIKERule or IPSecProposalInIPSecAction.
> >
> > If there is not a definitive reason for this (IMHO)
> > inconsistency, I would argue that the model should be changed
> > to replace the RuleForIPSecNegotiation and
> > RuleForIKENegotiation with a single association SARuleInPolicyGroup.
> >
> > BTW, despite my concerns our implementation remains true to
> > the current model as defined in
> > draft-ietf-ipsp-config-policy-model-04.txt.
> >
> > Casey
> >