Re: comments on ICPM

[Eric Vyncke <evyncke@xxxxxxxxx>]

Ricky,

Please find below a couple of answers (written by Lee -- our PCIM guru -- 
and myself)

Regards and Merry Xmas

-eric

At 14:43 11/12/2001 -0800, Ricky Charlet wrote:

>  Howdy,
>
>    Apologies for my poor timeing. I should have done this a month ago.
>
> Eric, Lee, Jamie... I'd actually like to get together while we are at IETF 
> so I can make sure I undersand some of these issues.  I'm open any time 
> there is no IPsec related  meeting.
>
>
> 1. (editing trivia) there seems to be no section 4.5. The doc skips from 
> 4.4 to 4.6.

ok

> 2. Thanks for the SANegotiationAction!!!!!

You are welcome

> 3. (in section 4.) in the case where we have an egress unprotected packet 
> which has been sucessfully matched to an ipsec rule and there is no 
> current SADB entry, we are instructed to used the "corresponding IKE 
> rule". But I cannot determine how to find an associated IKE rule. Is it 
> associated at the policyGroup level?  What I would strongly prefer, is to 
> have an associate IKE action along side of the IPsecAction both contained 
> simultaniously in the IKENegotiationAction.

[Eric]
Actually, you use the plain text egress packet first against the IPSecRules 
(= SPD) to get one IKE peer. Then if you have no SA, you can look into the 
IKERules for a IPHeaderFilter object matching the to be generated IKE 
packet (usually a match on HdrDstAddress). Another way is to use the 
PeerIDPayloadFilterEntry (typically for an aggressive mode responder).

Adding a new association between IPSecAction and IKENegotiationAction was 
not deemed as useful at the time of writing. One of our goal was to 
separate the IPSecRules (SPD) from the IKE negotiation one (notable to be 
as independent as possible from IKEv1).

> 4. (in section 4.2.1) we are inheriting a PolicyDecisionStrategy property 
> from PCIM. This seems bad to me in the case of IPsec. The 
> policyDecisionStrategy allows administrators to configure if they want to 
> do all matching rules or do only the highest priority matching rule. IPsec 
> specifically demands that we do only the highest priority matching rule. 
> And I'd strongly like to see a priority property re-introduced to 
> PolicyRule and PolicyGroup. Why on earth was it depricated based on input 
> from ICPM? I'm currently very unclear about how to administrativly order 
> policies. I do see that ICPM has added a priority property to the 
> aggrigation classes RuleForIkeNegotiation and RuleForIpsecNegotiation, but 
> these aggrigations can contain N rules and I don't see how to prioritize 
> within them. What am I missing here?...

[Lee]
From section 4.2.1: "if the property PolicyDecisionStrategy exists, it must
be set to "FirstMatching""
As you observed, the priority property is on the aggregation so that
priorities can be set in the specific context of its policy group.  When
PCIM defined it as a context independent property, it was an intractable
problem to determine the priority for a policyrule when it can be used in a
number of groups.

Each policysetcomponent aggregation (e.g., RuleForIPsecNegotiation) has a
priority value.  Perhaps the confusion is cleared up by observing that
there is an instance of the aggregation class for each aggregated rule.  So,
for example, in the context of a given IPsecPolicyGroup each rule has either
a RuleForIPsecNegotiation instance or a RuleForIKENegotiation instance and
that instance has a priority in it that applies only to that context (policy
group).  In a different policy group, the same rule can have a different
priority because it has a different aggregation instance.  IHTH.




> 5.  (in section 4.2.2) There are no examples of using the "Do until 
> failure" execution strategy. And I can not imagine how to use it myself. 
> What happens if there is a failure? Is that good in this case? What 
> happens if there is no failure and we reach the end of our actions? Would 
> we start over and do them again?

[Eric & Lee]
Indeed, we had no example of 'Do Until Failure' applicable to IPSec. We 
just left it in order to simplify the inheritance from PCIM.
BTW, if all your aggregated actions are success, then you do not have any 
failure, then the net effect is a failure ;-)


> 5. (in sect. 4.3.1) I think it is problematic to store individual context 
> names in alphabetical order... could we do administrativly configured 
> order instead?

[Lee]
The alphabetization is an arbitrary algorithm so that string compares can be
used to determine if compound contexts are the same.  When, for example, an
identity is used in multiple contexts, that list is not alphabetized; it's
only ordered when a given context name is a composition of values (e.g.,
"pki&&x.com&&y.com" defines an identity context).  This usage is generally
unnecessary since one can name a context without the composition operator
(e.g., "xy pki vpn").


> 7. (also in sect 4.3.1) I do not beleive that we need to make identity 
> selection a function of (local-endpoint, type, and name). It seems to me 
> that identity selection only needs to be a function of  (type and name).

[Lee]
Identities can be interface specific.  When an identity is shared by more
than one interface, one can associate a collection of IPPotocolEndpoint
instances to the identity.


> 8. (sect s 4.8.1 and 4.9.1)  Again, I'm unclear on why there are 
> priorities on the aggrigation classes but no priorities in the SARule or 
> IPsedPolicyGroup class. Some explanitory text may help here.

[Lee]
See #4 above.


> 9. (sect 4.9.3 and 4.10.2) should be a cardinality of 1..n ?

[Lee & Eric]
4.9.3: Since an IPsecPolicyGroup MAY be a structured set of groups, there's no
requirement that each group have both IKE and IPsec rules in it.

4.10.2: Conditions do not have an existence dependency on being used in a rule.
They're not terribly useful until they're in a rule, but they can exist
independently.


> 10. (sect 5.2) why must an IPHeaderFilter match traffic symetrically?

[Eric]
If your selectors for inbound & outbound are identical, then you should 
used 'mirrored' for simplicity (but you can define mirrored IPHeaderFilters 
if desired). NB: note the SHOULD in the text.

Else (asymmetrical selectors), obviously you should not use 'mirrored'.

> 11. (sect 5.3 and 5.5) what is the difference between a 
> CredentialFilterEntry and a PeerIdPayloadFilterEntry? Would we use a 
> CredentialFilterEntry when we specificall want to farm out the "good/bad" 
> decision to a credentialManagement service?

[Eric]

PeerIDPayloadFilterEntry: is a filter about the IKE identity used during 
phase 1 (FQDN, DN, IP address, ...).

CredentialFilterEntry is typically used when you expect this IKERule to be 
applied only for some credential services (like for this IKERUle, use this 
CA only).

> 12. (sect. 5.3.1) MatchFieldName seems underspecified. There is no 'stuff' 
> under the 'value' deffinition.
>
> 13. (sect. 5.3.2) MatchFieldValue seems underspecified. If we are matching 
> against DNs or GNs, we need a way to match the subparts of these 
> subjectNames and subjectAltNames and to wildcard match parts of them also.

[Eric]
It is indeed somehow underspecified.

The goal was to be able to filter based on subjectAltName using wildcard.

We should add (or have added) more examples and specifications.

> 14. (sect 5.3.3) what about PSK? (or dare I ask... xauth)

[Eric]
Xauth is out of the specification of ICPM.

If PSK means PreShared Key for IKE authentication, the secret is actually 
in the SharedSecret class from CIMUSER (cfr 6.6 for IPSec static session keys).

This should be (should have been) more specified.

> 15. (sect 5.4) who care?. Why are we doing Security Options filters? 
> Thanks for making it a MAY.

[Eric]
Our objective was to stick as close as possible to RFC 2401.

> 16. (sect 5.5) We deffinatly need to strike the phrase "when acting as a 
> responder" Both initiators and responders need to authenticate their 
> respective peers and both need a way to associate identities with peers. 
> Also the next sentence (beginning "Moreover, this filter can be ...) seems 
> unnecessary to me. That behaviour is specified elsewhere... I move to stike it.

[Eric]
This filter is used to reject IKE phase one when the remote is using a 
wrong/unacceptable ID.

And indeed, this filter could be applied in both responder and initiator modes.

> 17. (sect 5.5.2) we need a way to match the subparts of a subjectName and 
> subjectAltName (DN and GN) and a way to wildcard match the subparts.

[Eric]
The text should have been more explicit on how to match a DN (as we give 
only example for FQDN and IP addresses).

> 18. (sect 6.) I'd like vendors to have the freedom to add new actions as 
> siblings of SAAction. Specifically, I have in mind stuff like Firewall, 
> QOS, NAT, drop, bypass. Could we introduce a note in the text to this effect?

[Lee]
SAAction is a subclass of PolicyAction.  One can create new subclasses of
PolicyAction if one chooses to do so but it's not in the scope of this
document.  See PCIM and PCIMe.  But be aware that there are classes for drop
and bypass already (see SAStaticAction subclasses) and there are standards
activities for QOS policy.

[Eric]
In London meeting, I have orally made this comment.

> 19. (sect 6.1.1) the description of DoActionLogging seems vague to me. I'm 
> not sure what is meant by the phrase "when the action is performed". Is 
> this when a packet traverses this action, or is it when the action is 
> instantiated?

[Lee]
The DoActionLogging boolean tells whether the action of negotiating based on
that action is performed.  The DoPacketLogging boolean tells whether the
resulting SA is to do packet logging.

> 20. (sect 6.2) The description of SAStaticAction mentions that it is a 
> base class for IKE actions that do not require any negotiation. I don't 
> think there is any such thing.

[Lee]
An IKERejectAction is a subclass of SAStaticAction.

> 21. (sect 6.6)  In the notes area of PreconfiguredSAAction there is an 
> abbreviation "resp." used which I am guessing was meant to refer to 
> "Responder". But the use of the IKE term "Responder" would make no sence 
> in a description area of a static IPsec action. Can you clear this up for me.

[Eric]
Sorry for the confusion, probably a wrong English acronym has been used, I 
actually meant 'respectively'.

> 22. (sect 6.11.1) UsePFS seems to refer to PFS with respect to keys. Where 
> is a property to control PFS with respect to IDs?

[Eric]
Ricky, I do not understand what you mean by PFS with respect to ID ?


> 23. (sect 6.14.2) could we use simple assending interger values to 
> describe ExchangeMode instead of powers of 2?

[Eric]
It has been decided a long time ago, but, it was to have the same 
representation as on the wire (which is quite debatable of course)

> 24. (sect. 6.14.3) UseIKEIdentyType. The phrase "This information is to be 
> used in conjunction with the IKE identities..." is too vague for me. I 
> need to know how to find exactly which IKE identity is to be used in 
> association with this IKEAction.

[Lee]
See 8.6 IKEIdentity class and property descriptions.


> 25. (sect 6.15) peer gateway. I'm fuzzy about how this class interacts 
> with (or does not interact with) the CredentailFilterEntry and 
> PeerIdaPayloadFilterEntry classes. I think we have an IPsec and IKE rule 
> in hand by the time we get down to IPsecTunnelAction. Now the IKErule and 
> the IPsecAction:PeerGateway both seem to offer ways to identify the peer. 
> What are the distinctions between when these classes are applicable?

[Eric]
An egress plain text packet will trigger only one IPSecRule, one SAAction 
of the IPSecRule will possibly request a IKE negotiation with one PeerGateway.

Once a possible PeerGateway is known, the IKERules are checked to select 
the relevant IKENegotiationAction.


> 26. (sect 6.15.3) PeerIdentity seems underspecified. I think we would need 
> an ID payload type and in the case of DN or GN, ways to match and wildcard 
> match the subfields of the subjectName or subjectAltName.

[Lee & Eric]
See PeerIdentityType.

We should have added some more descriptive text.

> 27. (sect. 6.16.3) is a sequence nukmber on peer gateways still needed now 
> that the ExecutionStrategy property has been introduce to the SARule?

[Lee]

Yes, the ExecutionStrategy and sequence numbers specify the order in which
actions are attempted.  The gateway selection is within a given action.  One
might argue for this being an implementation decision rather than a policy
decision, but it doesn't have anything to do with ExecutionStrategy and
action ordering.

> 28. (sect 6.18) Again, something I'm not understanding here. Do we need to 
> keep a table of "systems" for all of our peers? And why do we care about 
> associating our IKE peers with the information availabl in the "System" class?

[Lee]
The HostedPeerGatewayInformation association simply anchors the "table" of
peer gateways, nothing more.  The system instance is the system that hosts
the local IKEService.


> 29. (sect 7.2.4) the VALUE deffinition of PRFAlgorithm says "currently 
> none defined". While this is true, I'd rather say "see IKE"  (or see DOI, 
> I didn't look up which was approprate for this).

[Eric]
Good point


> 30. (sect 7.2.5) setting groupID to the value "notNeeded" is poor 
> configuration design. It puts two knobs in the hands of an adminstrator 
> (both of which must be set correctly) to do only one task. Instead I'd 
> rather see us say that if the ExchangeMode is agressive, then the GroupId 
> property will not be used reguardless of its setting.

[Eric]

Good point as well.

> 31. (sect 7.2.6)  I don't like having the "special value 0" on the 
> AuthenticationMethod poperty. Since there can be N saProposals on an 
> IKENegotiationAction I think we can list the IKEproposals with the 
> IKEauthentication methods we want to use explicitly rather than having a 
> setting for "just make a proposal for each applicable credential I have". 
> And even if we did keep the "special value 0" thing, it seems like we 
> would need to distinguis beteen authentication methods if we had an RSA 
> cert credential. We would not completely know if we should use rsaEncrypt 
> or revisedRsaEncrypt autenhtication methods.
>
> 32. (sect 7.8) yet another please explain this to me... Why would we want 
> to associate SAProposals with the poperties available in the System class?
>
> 33. (note: I'm skipping review of the IKEServices stuff).

[Eric]
Shame on you ! ;-)


> 34. What happens to my configuration if one of my IPaddresses is changed 
> (ie by dhcp or ppp or a human...)

[Lee]
It changes too; at least to the extent that configuration is anchored on an
address.

[Eric]
And this is strict compliance to RFC 2401.


> 35. Could we parallize the names SAConditionInRule and PolicyActionInSaRule?

[Lee]
If you mean change the name of SAConditionInRule to SAConditionInSARule, I
suppose so...if it's really important to you.

[Eric]

;-)

Thanks for your comments

-eric & others