Subject: comments on ICPM

From: Ricky Charlet <[email-masked]>
Date: Tue, 11 Dec 2001 14:43:53 -0800

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.

2. Thanks for the SANegotiationAction!!!!!

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.

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?...

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?

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?

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).

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.

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

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

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?

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.

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

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

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.

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.

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?

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?

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.

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.

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?

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

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.

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?

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.

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?

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?

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.

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).

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

35. Could we parallize the names SAConditionInRule and PolicyActionInSaRule?

--
Ricky Charlet

---

From: Ricky Charlet <[email-masked]>
Date: Fri, 14 Dec 2001 09:50:53 -0800

(note my email address has changed to [email-masked])

Howdy,

    Of  the 30 or so listed items in my post, I think there are only 2 
'big rock' issues. And I'd like to add one new issue...

1. I propose a substantial modification of attaching an IKE action to an 
IPsec action directly for egress unprotected packet in stead of using a 
secondary IKE rule lookup after the IPsec rule lookup. This has 
implications for moving contexts also.

2. credentialFilters and IDPayloadFilters are deeply underspecified in 
my opinion. I intend to produce some suggested additional text as a 
strawman so people can see what I mean.

3. (new) I'd like to see the IPsecBypass, IPsecReject, and IkeReject 
actions moved in the model to be peers with saStaticAction & 
saNegotiationAction under SAAction. Where they are now, they inherit a 
'lifetime' property which makes no sence. Secondarily, I'd hope to seem 
them consolidated to bypass and reject instead of ipSecBypass, 
IPSecReject and IkeReject.

Most of the other things are requests for clarifications. They could be 
solved either with additional descripive text or me being less dence. 
Since I've given up hope for becoming less dence, I would like to see 
additional descriptive text added in those areas.

Ricky Charlet
[email-masked]

Ricky Charlet wrote:

> 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.
>
> 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.
>
> 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?...
>
>
> 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?
>
> 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).
>
> priorities on the aggrigation classes but no priorities in the SARule 
> or IPsedPolicyGroup class. Some explanitory text may help here.
>
>
> 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.
>
> 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?
>
> 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?
>
> base class for IKE actions that do not require any negotiation. I 
> don't think there is any such thing.
>
> "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.
>
> 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.
>
> 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?
>
> 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?
>
> 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.
>
> IKEauthentication methods we want to use explicitly rather than having 
> a setting for "just make a proposal for each applicable credential I 
> 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.
>
> want to associate SAProposals with the poperties available in the 
> System class?
>
> 34. What happens to my configuration if one of my IPaddresses is 
> changed (ie by dhcp or ppp or a human...)
>

---

From: Eric Vyncke <[email-masked]>
Date: Fri, 21 Dec 2001 16:00:25 +0100

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:

>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.
>
>

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 
>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.

>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").

>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.

>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'.

>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.

>Thanks for making it a MAY.

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

>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).

>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.

>think there is any such thing.

[Lee]
An IKERejectAction is a subclass of SAStaticAction.

>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 ?

>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 

[Lee]
See 8.6 IKEIdentity class and property descriptions.

>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.

>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

>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.

>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?
>

[Eric]
Shame on you ! ;-)

>(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