Hi,
I reviewed draft-ietf-ipsecme-ikev2-diet-esp-extension a while ago.
Since then, the document is improved. I believe it still have some places
that need
to be clarified. Below are my comments on -07 version.
1. Section 3.
Please clarify where the HCP_PROPOSAL should be present in case of
multi-round
IKE_AUTH (I assume it must be in messages containing SA payload for
Child SA,
but it is better to spell this out).
2. Section 3.
What if multiple HCP_PROPOSAL notifications appear in a message? How it
should be interpreted?
Or is it prohibited?
3. Section 3.
"If none of the received Proposals are deemed acceptable,
the responder MAY choose to discard the HCP_PROPOSAL Notify Payload.
Nevertheless, it is anticipated that the responder will provide an
explanation for rejecting all HCP Proposals. If the reason pertains
to an AfRD with an unacceptable value, the responder SHOULD reply
with a NO_PROPOSAL_CHOSEN Notify Payload. "
I think you should elaborate. Basically, you may want to distinguish
between the case
when the responder does not support this extension (and, thus, it will
ignore the notification)
and the case, when the responder supports this extension, but cannot
choose from the
proposed values (since below you allow the initiator to restart with a
different set of proposals).
For this reason, I don't think that NO_PROPOSAL_CHOSEN is a good idea,
since it gives no
information for the initiator whether this extension is supported or
not.
I would expect that instead of returning NO_PROPOSAL_CHOSEN the
responder that supports
this extension just creates a Child SA (as if it does not support the
extension), but also returns
HCP_PROPOSAL in some special form (e.g, with some reserved HCP Name) and
a list of unacceptable AfRD.
If the initiator is not happy with uncompressed SA, it can delete it and
propose a different range of values.
4. Section 3.
"In cases where the AfRD was not explicitly stated, the
responder will provide the AfRD unless it defaults to a standard
value."
This is not clear for me. What is a "standard value" here?
5. Sections 3, 4 and Figure 1.
s/HCP_PROPOSAL_CHOSEN/HCP_PROPOSAL
6. Figure 1.
s/Proposal_ID/Proposal ID
7. Section 4.
" To avoid ambiguity, it is explicitly required that both AfRD_min and
AfRD_max refer to the same type of parameter and that they are
processed as attributes with values defining the minimum and maximum
of the range."
I think using "MUST" is appropriate here.
8. Section 8.
You are asking IANA to create ne registries for HCP. It is not clear
where these registries should be created - in the IKEv2 IANA registry
page or elsewhere?
I also wonder why the policy is "Specification required" and not
"Expert review".
Any justification? Do you expect running out of codepoints?
9. Section 8.3.
I think that having a Reserved value can be useful (e.g., see my
proposal on negotiation).
10. Section 8.4.
s/CHILD SA/Child Sa
11. Section 8.5.
All registries in this section have 255 as a maximum value. Is there
any reason
for this, taking into consideration that they present in Attribute
Data, which has 16 bits size?
And another point - you don't have reserved values (perhaps it is OK
here, don't know)
and don't specify private use ranges. Is it intentional?
Regards,
Valery.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
