[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on ICPM
Please find below a couple of answers (written by Lee -- our PCIM guru --
Regards and Merry Xmas
At 14:43 11/12/2001 -0800, Ricky Charlet wrote:
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.
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.
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?...
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
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).
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.
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
10. (sect 5.2) why must an IPHeaderFilter match traffic symetrically?
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?
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
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.
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)
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.
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.
This filter is used to reject IKE phase one when the remote is using a
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.
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?
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.
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
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.
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.
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?
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?
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.
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?
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]
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?
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
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?
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).
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.
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).
Shame on you ! ;-)
34. What happens to my configuration if one of my IPaddresses is changed
(ie by dhcp or ppp or a human...)
It changes too; at least to the extent that configuration is anchored on an
And this is strict compliance to RFC 2401.
35. Could we parallize the names SAConditionInRule and PolicyActionInSaRule?
If you mean change the name of SAConditionInRule to SAConditionInSARule, I
suppose so...if it's really important to you.
Thanks for your comments
-eric & others