Reviewer: Gorry Fairhurst
Review result: Almost Ready
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
I'm not an expert in IPPM nor in security, so I am read this seeking to
understand the requirements for the protocol interactions. The method adds meta
data to existing packets, as such it does not introduce significant increase in
the transmission rate and seems unlikely to contribute new congestion control
considerations. I did find places where the mechanism appears to be unclear,
and a mention of QoS which seems to require some work.
* What is the relationship with other PDM documents?
The document makes no mention of the standards status of the existing PDM spec,
although I later understand that this is a negoiciated variant and both are
expected to co-exist. This ought to be clear: Is this spec an additional format
or replacement? Is that spec deprecated? Should this spect obsolete/deprecate
RFC 8250?
Does this document update any other specification, in which case the boiler
plate and the abstract ought to say so?
The following specific comments relate to specific sections in this document.
Abstract
----
The abstract states:
“RFC8250 describes an optional Destination Option (DO) header embedded in each
packet to provide sequence numbers and timing information as a basis for
measurements.“ - I think the normal term is that the EH is “included” rather
than “embedded”? - I also wonder if this is being specified for IPv4 (I think
not?), if not then I think this document ought to insert “IPv6” before packet
in the abstract.
---
Is this defined only for unicast addresses, later the document states “Global
Unicast addresses.”, in which case, ought the abstract and introduction to
define this limited scope - or is this applicable to or extensible to anycast
and multicast use?
---
“As this data is sent in clear-text, this may create an opportunity for
malicious actors” - I think this is /Because/ and I expect that /may
create/creates/ is more accurate, the opportunity is created, the effect can be
mitigated. /PDMv2 which has/PDMv2, which has/
---
Please expand PDM to Performance and Destinations Metrics in the abstract.
---
“Additional performance metrics which may be of use
are also defined.”
- could perhaps be clearer as:
“Additional performance metrics are also defined.”, without speculating on the
usefulness?
---
1. Introduction.
----
- The Introduction section needs additional editorial work to produce readable
english, and also needs the set of examples and use-cases to be clearly
explained.
---
I wonder if this phrase makes sense to people:
“measure the Quality of Service (QoS)“
- Can someone really measure something that is configured?
- I expect you can measure a path that is designed to support a certain QoS. Is
there a better wording?
---
“and to assist in diagnostics”
- This seems like it could be useful, but the current text does not say say
anything about what sort of diagnostics or what is the intended use?
---
“For example, the operational
capabilities of either the client or server end hosts such as
processing speed -- that is, if the system in question is very fast
system or an older, slower device.”
- This and the following examples seem to be rather incomplete: For example,
this does not explain the vulnerability or the exploit, please explain.
---
3.2 - Is this only for directly carrying transport protocols?
All the examples provided as examples for PROTC seem to be upper-layer
transport protocols, is it possible to use this with an encapsulation or other
EH? - If so please add some examples here. - What is the format of this header?
---
5.2
“Alternatively, the network administrator might choose to create a
policy that prohibits the use of PDM or unencrypted PDMv2 on their
network. The implementation SHOULD provide a way for the network
administrator to enforce such a policy.”
- I can see this is an alternative, but what is the RFC2119 requirement
intended to test/require? Is this really a useful requirement, or could this be
a case where we do not need RFC 2119 language?
----
“ The server and client implementations SHOULD support PDM, unencrypted PDMv2,
and encrypted PDMv2. “
- I think this is not easy to understand. Why is this a SHOULD? If it
implements this specification, doesn’t it support some of these. I’m unclear.
Sections 5.2.1 and 5.2.2 seem to describe use cases where a server does not
understand PDM or PDMv2, and that is also confusing for me.
---
“If a client chooses a certain mechanism
(e.g., PDM), the server MAY respond with the same mechanism, unless
the network administrator has selected a policy that only allows
certain mechanisms on their network.”
- This seems important, but I do not understand what needs to be implemented
and what needs to be configured from this text.
---
Section 6.3
“An unauthorized party MUST NOT be able to send PDM data and MUST NOT
be able to authorize another entity to do so. Alternatively, if
authentication is done via any of the following, this requirement MAY
be considered to be met.”
- I’m unsure what the RFC2119 requirement is in this case. I think this is not
a compliance.
---
I think the following applies only to the PDM option data, is that correct
(please say):
“Confidentiality: Encryption ensures that the actual content of
the communication remains confidential. Even if attackers or
observers intercept the data packets, they won't be able to
decipher the information without the encryption key. In the case
of IPv6 Performance and Destination Option (PDM), the still-
visible, non-encrypted metadata is still visiblenegligible, and
does not poses confidentiality.”
---
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
