Hi,
I read through draft-ietf-ipsecme-encrypted-esp-ping-02. I think that the text
needs more polishing.
Below are some comments.
1. Abstract
"A peer MAY announce the support using a new IKEv2 Status Notifcation
ENCRYPTED_PING_SUPPORTED.":
a. typo s/Notifcation/Notification
b. RFC2119 keywords must not be used in Abstract
2. Section 1
"The IPsec peer may announce its capability to support Encrypted ESP Ping
using an IKEv2 Notification Status Type."
I wonder why "may"? If peers do not negotiate support for this feature,
then how the result of the encrypted ping
can be reliably interpreted in case no response is received?
3. Section 1.1
The term " Return Path Specified LSP Ping" is not used in the document
(only "LSP ping" is used once).
Do you need to specify this term? Perhaps it's easy to expand what is "LSP
ping" where it is used
and remove this definition.
4. Section 3.3
"When there are multiple paths, the Encrypted ESP Ping should support
requesting an echo response via a
specific return path IPsec SA."
Shouldn't "should" be "SHOULD"?
5. Section 3.3
"If the initiator requests a return path, the responder SHOULD try to
respond via that path, IPsec SA."
I would suggest to rephrase this for readability; either remove ", IPsec
SA" or remove "path,".
6. Section 3.3
"If the responder
decides to send the response via a different path than the requested
return path, the initiator SHOULD notice it and notify the initiator
application."
What is meant by "notify the initiator application"? What application, if
ping
request was initiated by IPsec module itself? How to notify? What it is
supposed
to do with this notification?
7. Section 3.3
"An example is Return Path Specified LSP ping specified in [RFC7110]."
I'm not sure this reference is helpful unless more clarifications are added
why it is helpful. Perhaps just mention somewhere in the Introduction
that this document is similar to approach defined in RFC 7110 and remove
this sentence.
8. Section 3.4
It is not clear for me how this section is related to the scope of the
document.
Perhaps some clarifications are needed.
9. Section 3.4
IP-TFS should be expanded here and a reference to RFC 9347should be added.
10. Section 3.6
"Incoming SA traffic counters are unique to
IPsec compared to other tunneling or native IP connections. In
IPsec, the incoming counters reliably indicate a viable path."
What are "SA traffic counters"?
11. Section 4
"The ESP Echo Request packet must be encrypted." and late "the ESP Echo
Response MUST be encrypted"
I wonder why it must be encrypted. It is sent over ESP and as any other
traffic
sent over an SA receives the same level of protection. For example, if
AES-GMAC
is negotiated for this SA, encryption is not possible.
12. Section 4
"If the SPIs
are negotiated it SHOULD utilize an SPI value previously negotiated,
e.g. negotiated through IKEv2."
What other options exist? Use random SPI? Then how to protect ping with
non-existing SA?
13. Section 4
"The initiator sets the ESP Next Header value to AGGFRAG_PAYLOAD which
has the value 144, as specified in [RFC9347]. This can be followed
by different echo request sub-type payloads with a well defined
format and optional empty data blocks following it"
It is not clear how the Next Header field can be followed by anything, since
it is
the last field in ESP packet. Please, rephrase.
14. Section 4.
"AGGFRAG_PAYLOAD Payload starts from ESP Next Header value: 144 and
followed one of the two Request payloads specified."
The ESP Next Header value is the last field in ESP, followed only by ICV.
Please, rephrase.
15. Section 4.1
From my understanding reading so far, two different formats for encrypted
ESP ping
are possible - one re-using AGGFRAG Congestion Control and the other one
defined
in Section 4.2. If so, it must be made more clear before.
typos s/This this/This s/ a nd/and s/padding padding/padding
s/of the the/if the
16. Section 4.2
Figure is broken (R field is misplaced)
17. Section 4.2
"Response copy it from the request"
Responder copies?
18. Section 4.2
"The responder SHOULD copy the request message and MUST change the
Sub-type to ESP-ECHO-RESPONSE."
What alternatives are possible for SHOULD?
19. Section 4.3
"However,the responder MAY respond to the peer
using its default Security Parameter Index (SPI)."
What is the "default SPI"?
20. Section 5
Since negotiation is optional, I think that the document must be more
specific on how
to interpret the lack of response in case the encrypted ping is not
negotiated.
Should it continue to ping its peer, or give up? Should it use SA or try to
create another one
(e.g. with a different transport)? I believe that optionality of
negotiation undermines
the usefulness of this feature.
21. Section 6
"This document updates [RFC9347] to allow ESP Echo Request and ESP
Echo Response without a successful negotiation of USE_AGGFRAG."
I believe this text is misplaced - it must not be in IANA Considerations.
And if this document updates RFC 9347, then it must be stated in metadata,
Abstract and Introduction.
22. Section 6
2 ESP-ECHO-REQUEST [this document]
3 ESP-ECHO-RESPONSE [this document]
Why concrete values are specified here and are not requested from IANA?
23. Section 10
RFC8194 is not referenced.
I wonder why all references are normative (including those that definitely
are not needed to implement this functionality).
Regards,
Valery.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
