IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-07-06. These are not an official record of the meeting.
Narrative scribe: John Leslie and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: Spencer
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
1)
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg |
|------- |
| \ StartTLS |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
|:::::::::TLS:::::::::| TLS Establishment
|:::::Establishment:::| Failure
| |
|<--------------------| Send Error-Type TBA2
| PCErr | Error-Value 3/4
| |
Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot
establish TLS
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
Telechat:
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
3.1.2 Returning items
Telechat:
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
7a. Other Business
1051 EDT Adjourned
(at 2017-08-03 05:45:21 PDT)
draft-ietf-dmm-mag-multihoming
1) Sec 3.2: "Packet distribution can be done
either at the transport level, e.g. using MPTCP or at When
operating at the IP packet level, different packets distribution
algorithms are possible. " is clearly not a properly written sentence.
I also share Mirja's concerns about TCP inside TCP.
2) Sec 4.1: "This flag MUST NOT be set to a
value of (1), if the value of the Registration Overwrite Flag (O)
is set to a value of (1).
Binding Overwrite (O)"
Please make the draft consistent as to the name of the flag (O)
Section 3.2. Traffic distribution schemes "Per-packet management: the LMA and the MAG distribute packets, belonging to a same IP flow, over more than one bindings (i.e. more than one WAN interface)." This immediately made my out-of-order-packets antenna pop up, so I read the section looking for mitigations. The very next sentence reads: "Packet distribution can be done either at the transport level, e.g. using MPTCP or at When operating at the IP packet level, different packets distribution algorithms are possible. " -- the fact that this sentence is a: malformed and b: hand-wavy did nothing to allay my concerns, so I read further: "The distribution algorithm is left to implementer but whatever the algorithm is, packets distribution likely introduces packet latency and out-of-order delivery. LMA and MAG shall thus be able to make reordering before packets delivery." - I agree with the first sentence (although it is poorly worded), but the second sentence doesn't follow from the first; "shall thus be able to" implies that the prior text somehow provides a solution, not points out a problem (the sentence is also malformed)-- I think you mean something like "The LMA and MAG thus need to be able reorder packets to their original order before delivery." This then continues with "Sequence number can be can be used for that purpose, for example using GRE with sequence number option [RFC5845]." - I think that the actual reference should be RFC2890, but regardless of this, I don't think that what you are proposing works - "The Sequence Number field is used to maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, emphasis added). This means that sequence numbers are local to the tunnel, and (as I understand it) your solution involves diverse tunnels. Further, Section 2.2. Sequence Number says: "The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by sequence number." - if you are proposing using a single sequence number space for multiple tunnels, you will end up with sequence number space gabs, and lots of buffering, etc. The section ends with: "However, more detailed considerations on reordering and IP packet distribution scheme (e.g. definition of packets distribution algorithm) are out the scope of this document." - I think that, unless the prior paragraph is significantly reworked, it should not try and suggest any mitigations. The whole idea of striping packets of a flow across (notably) different transports seems like a really bad idea to me -- is it actually needed?
Nit: IANA-3 value is referenced in the IANA Considerations, but is not used. I think you meant IANA-4 in the place where IANA-3 is currently referenced.
I have a few editorial comments/nits: - There are several acronyms that should be expanded on first mention. (including at least a couple that are expanded on _second_ mention (MAG and LMA). - 3.2, "Per-packet management" bullet: The second sentence does not make sense. - 3.2, last paragraph: Are we really talking about the latency introduced by per-packet management, or jitter (i.e. variation in latency)? - 4.1, definition of "Interface Label": This doesn't really define the term "interface label". It talks about how it is used, but not what it represents.
Thank you for making the change to address Mirja's Discuss, which I agreed with. I also agree with your proposed resolution.
Thanks for your work on this draft. I had the same concern as the SecDir reviewer in reading the draft, the concern about leaking traffic as a result of multiple tunnels is not addressed in the security considerations section. Hilary's writeup is quite helpful https://www.ietf.org/mail-archive/web/secdir/current/msg07446.html
1) This document should not recommend the use of MPTCP for tunneling, as TCP-in-TCP tunnels are generally not recommend if that can be avoided. Please remove the following part from section 3.2 and leave IP-level tunneling as the only option: „Packet distribution can be done either at the transport level, e.g. using MPTCP …“ 2) Further the following sentences also in section 3.2 should be revised: „For example, high throughput services (e.g. video streaming) may benefit from per-packet distribution scheme, while latency sensitive applications (e.g. VoIP) are not be spread over different WAN paths.“ High throughput services only benefit from per-packet scheduling if the service requires higher throughput than one of the links can provide. Also video streaming may not be a good example here because high latency variations can lead to stalls. Therefore in general per-flow scheduling should be recommend for all traffic. It could still be beneficial to schedule flows that require low latency over the link with the lower base latency, or maybe more important lower jitter, however, often it is not known to the network what the requirements on latency are for a given flow. Therefore is should probably be recommended to schedule all traffic on the "better" link (where better can be pre-configured knowledge or measured) as long as the bandwidth of the incoming traffic is smaller than the bandwidth of the that link, and only use a second link (with per-flow scheduling) if the capacity is required. 3) This document does not really normative specify the use of the newly defined options. It only gives an examples but it does not specify normatively any actions that need to performed on receipt of these options. How does the MAG know if the LMA does not support Multipath binding? An LMA that does not implement this spec will not send back an error message. Why are there two different options? What happens if one of the options is present in the Proxy Binding Update but not the other?
Please also clarify the definitions of Interface Label and Binding Identifier as requested by the gen-art review (Thanks Robert!)
draft-ietf-trill-mtu-negotiation
I echo Mirja's thanks for your work addressing Magnus's TSV-ART review.
[ I have removed my DISCUSS after discussing this with Alia. She has reassured me that there has been sufficient discussion on the topic, so I'm a happy camper now... ] Major: I found much of the document really hard to read - I approve of the concept / see the need for this, but reading the document itself is not well written. Nits: General RFC 6325 says: "4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size In a stable campus, there must ultimately be agreement among all RBridges on the value of "Sz", the minimum acceptable inter-RBridge link size for the campus, for the proper operation of TRILL IS-IS." and this document says: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" " Ok, so Sz is campus-wide -- but, for some reason this document has ~35 instances of "campus-wide Sz" - can you just drop the "campus-wide"? Is there any time the Sz would not be campus-wide? Section 1. "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the campus-wide "Sz" to ensure that link state flooding operates properly and all RBridges converge to the same link state." This is really hard to parse - the bit before the hyphen is fine, but then it gets muddled. Perhaps: "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called "Sz") to ensure that link state flooding operates properly and all RBridges converge to the same link state." "By calculating and using Lz as specified herein, link-scoped PDUs can be formatted greater than the campus-wide Sz up to the link-wide minimum acceptable inter- RBridge MTU size potentially improving the efficiency of link utilization and speeding link state convergence." "formatted" seems clumsy - perhaps just drop it? Or reorder to be "link-scoped PDUs larger than Sz, up to ... can be used"? O: "The new MTU size testing method specified in this document is backward compatible to the old one." P: "The new MTU size testing method specified in this document is backward compatible with the old one." C: Grammar O: "Link-wide Lz is the minimum Lz supported and agreed between all RBridges on a specific link." P: "Link-wide Lz is the minimum Lz supported and agreed amongst all RBridges on a specific link." C: Between only if two. Section 2. Link-Wide TRILL MTU Size O: "These PDUs are exchanged just on the local link." P: "These PDUs are exchanged only on the local link." O: "They use that flooding to exchange their maximally supportable value of "Lz"." P: "They use that flooding to exchange their maximum supported value of "Lz"." C: Maximally would be an adverb, describing the process of maximizing the flooding (or something). Section 2.1: O: "Lz MAY be reported using a originatingSNPBufferSize TLV that occurs" P: "Lz MAY be reported using an originatingSNPBufferSize TLV that occurs" C: I think. O: "If RB2 sends PDUs formatted in chunk of size 1800, it will be discarded by B1." P: "If RB2 sends PDUs formatted in chunks of size 1800, they will be discarded by B1." C: chunks is plural. Section 6: "The CSNPs and PSNPs MUST be formatted in chunks of size at most the link-wide Lz but are processed normally if received larger than that size." -- why the MUST? Is this supposed to be an instance of the sender being conservative and the receiver liberal? It so, I think it would be better to be much clearer. Section 7: O: "Unlike RBridges, end stations do not participate in the exchange of TRILL IS-IS PDUs, therefore they cannot grasp the traffic link MTU size from a TRILL campus automatically. " C: should be a semicolon and not a comma before therefore, and a comma after therefore. Section 8. Backwards Compatibility O: "This will act properly although it may not be as efficient as it would be if all RBridges on the link are Lz-aware." P: "This will act properly although, it may not be as efficient as it would be if all RBridges on the link are Lz-aware." C: Missing comma. "Then the path MTU can be set as the smallest tested link MTU on this path and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." -- instead: "Then, the path MTU can be set as the smallest tested link MTU on this path; and end stations should not generate frames that, when encapsulated as TRILL Data packets, exceed this path MTU." -- Original discuss for posterity -- 1: Instead of answering the questions, the Shepherd Writeup just has links to things - for example: (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? WG LC: Passed: https://www.ietf.org/mail-archive/web/trill/current/msg07304.html Discussion: https://www.ietf.org/mail-archive/web/trill/current/msg07210.html This caused me to go investigate further - it seems that there were only 4 comments received during WGLC (excluding the RtgDir review, a short exchange with Julien Meuric). The comments which *were* received largely just fell into the "Support" (with no real discussion) category. The document was adopted 06 March 2015, and then there were a few automated mentions of it (e.g [0], [1]), but I see no real discussion of the draft *in the WG*. It is entirely possible that my search fu is weak today, and that there has been sufficient discussion and review of the draft (or that none was needed because it is so obviously right and pure, but I'd like some reassurance of that), especially because a quick review found multiple readability issues / nits. Note: I'm not holding the discuss on the readability / nits, rather on has the process been followed / is there consensus grounds 2: The document also says that it Updates: 6325, 7177, 7780 - but I don't see clear discussion of the Updates (OLD / NEW). [0]: https://mailarchive.ietf.org/arch/msg/rtg-dir/c863sUajt86YB_d62uWfF5Hd_X4 [1]: https://mailarchive.ietf.org/arch/msg/i-d-announce/p5ROVvvoU0B3S1OA2SY3vebX_b4
Thanks for adressing the tsv-art comments (and thanks to Magnus for the tsv-artt review)! It might still be valuable to note that RTT estimation is out-of scope for this document and if the RTT can not estimed acoordingly an conservative upper bound estimation should be assumed.
Thanks for resolving my comment on version 06.
Are there implementations of this optimization? Have they shown the expected improvements? The mechanism seems ok, but the introductory text made we wonder, specially the part about "*potentially* improving the efficiency of link utilization and speeding link state convergence." IOW, if the advantages are not really know, then maybe a Standards Track document is premature. I really don't have a strong opinion, so I'm just wondering at this point. Some nits: 1. There are some places where rfc2119 language is used that I think is out of place because it is really just stating a fact or quoting what different documents say (without actually using quotations); IOW, these are really not normative statements defined in this document: - "[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU...all RBridges MUST format their LSPs..." - "As specified in [RFC8139], RBridges MUST support..." - "as required by [RFC7780], all RBridges MUST..." 2. From 2.1, these 2 sentences are redundant: "An originatingSNPBufferSize APPsub-TLV occurring in any other fragment MUST be ignored. An originatingSNPBufferSize APPsub-TLV occurring in any other fragment is ignored. "
draft-ietf-teas-gmpls-lsp-fastreroute
1) In Sec 4.5.1: "The downstream PLR can assign a bypass tunnel when
processing the first Path message of the protected LSP, however, it
can not update the forwarding plane until it receives the Resv
message containing the downstream MP label."
Please explain how the downstream PLR can assign a bypass tunnel if the LSP
has a loose ERO - so the downstream PLR does not know the next-next-hop that
would be the MP for a node-protecting LSP.
2) Sec 4.5.1: "An upstream PLR (downstream MP) SHOULD check all
BYPASS_ASSIGNMENT
subobjects in the Path RRO in order to assign a reverse bypass
tunnel. The upstream PLR that detects a BYPASS_ASSIGNMENT subobject,
selects a reverse bypass tunnel that terminates locally with the
destination address and tunnel-ID from the subobject, and has a
source address matching the Node-ID address."
This isn't very clear - particularly given that there will be many
BYPASS_ASSIGNMENT subobjects in the path RRO. The case of BYPASS_ASSIGNMENT
sub-objects being removed or changed is not addressed at all. In addition, I
*assume* that the failure to treat the destination IP address in the
BYPASS_ASSIGNMENT as the source IP address for the upstream Bypass tunnel is an
oversight?
I believe that what is meant is:
"An upstream PLR (downstream MP) SHOULD check all BYPASS_ASSIGNMENT sub-objects
in the Path RRO to see if the destination IP address in the BYPASS_ASSIGNMENT
matches an address of the upstream PLR. For each BYPASS_ASSIGNMENT sub-object
that matches, the upstream PLR looks for a local bypass tunnel that has a
destination matching the downstream PLR that inserted the BYPASS_ASSIGNMENT, as
indicated by the Node-ID address, and the same tunnel-ID as indicated in the
BYPASS_ASSIGNMENT."
I recall that tunnel-ID is usually scoped by the address of the ingress LSR;
this seems to assume that the same tunnel-ID is provided to both the downstream
PLR and upstream PLR??? Alternately, I am misunderstanding - and the
information in the BYPASS_ASSIGNMENT is really intended to be bypass tunnel to
be used by the upstream PLR, which the downstream PLR somehow(??details, hints
in the document please) knows .
Then there needs to be text to handle the case where the previous PATH message
contained a particular BYPASS_ASSIGNMENT sub-object and that sub-object has
been removed or changed.
3) Sec 4.5.3: "In both examples above, the upstream PLR SHOULD send a Notify
message
[RFC3473] with Error-code - FRR Bypass Assignment Error (value: TBA1)
and Sub-code - Bypass Assignment Cannot Be Used (value: TBA2) to the
downstream PLR to indicate that it cannot use the bypass tunnel
assignment in the reverse direction. Upon receiving this error, the
downstream PLR MAY remove the bypass tunnel assignment and select an
alternate bypass tunnel if one available."
This section is problematic because it creates the use of local policy when the
ingress has a clear way to signal what type of protection is desired and
because it provides an error message to where it will only cause pointless
churn (the MP is the MP based on the type of protection desired - certainly for
bypass) rather than to the ingress where it could at least be acted upon. The
dynamics at time of failure also do not seem to be well considered; asymmetry
is unfortunate, but worse is lack of protection.
Consider the case in Example 1. If R5 suffers a node failure, then there is no
protection for the upstream LSP from R6 if it prefers the link protection. It
simply doesn't matter what bypass tunnel R4 picks! Sending a Notify message to
R4 asking for a different tunnel is not productive. If the ingress has
requested node-protection, then there is simply nothing that can be done for
this topology by R5. It could be helpful to send a Notify to the ingress or
have a flag set in the RESV RRO to indicate the issue, but that's about it.
For the question about creating local policy, how are the SESSION_ATTRIBUTES
used? Obviously, they are available in the PATH message that has the
BYPASS_ASSIGNMENTs. Why would the "Node Protection Desired" flag not be
relevant here?
4) Sec 5: " o Upstream PLR reroutes traffic upon detecting the link failure
or
upon receiving RSVP Path message over the bidirectional bypass
tunnel.
o Upstream PLR also reroutes RSVP Resv signaling after receiving
RSVP Path message over the bidirectional bypass tunnel. "
How does the upstream PLR detect that the message was received over the bypass
tunnel? Is the assumption that the bypass LSP doesn't do penultimate hop
popping? Is the assumption that the PLR can tell because RSVP indicates the
downstream PLR as the previous hop in its signaling? Please clarify and
describe how this detection is done - to ease interoperability.
5) In Sec 5.1.2: "When upstream PLR R4 receives the protected LSP Path
messages over
the restored link, if not already done, it starts sending Resv
messages and traffic flow of the protected LSP over the restored
link and stops sending them over the bypass tunnel."
Is there a reason that "when the downstream PLR receives the protected LSP RESV
messages over the restored link, if not already done, it starts sending Path
messages and traffic flow of the protected LSP over the restored link and stops
sending them over the bypass tunnel." doesn't also make sense to put in this
section?
If this is not a good idea, please explain clearly the issues that it causes.
I am assuming that "after the link is restored" implies that bidirectional
communication has been successfully tested - not merely that the physical layer
is up but also that an IGP or BFD is successful across it. (But this is
standard for RSVP-TE FRR).
6) Sec 5.2.2: The behavior of R4 is not described. When the link from R3-R4
fails, R4 will redirect traffic to R2. As written at the start of Sec 5, R4
does not start sending its Resv across the bypass tunnel and R2 is thus not
triggered to use its bypass tunnel. Please clearly describe this and why. It
is this asymmetry in behavior for the downstream PLR and upstream PLR that
causes the downstream PLR's bypass tunnel to be prioritized.
7) Sec 5.2.2: The need for the PRR to look up the bypass tunnel and then
reprogram the forwarding plane is quite concerning for having this operate at
significant scale. What could be done if one assumes that the selected bypass
tunnel - from the BYPASS_PROTECTION handling - is used? Is there a reason that
decision has to be redone here? What is the issue that the solution is trying
to work around? I can certainly imagine scenarios with BFD sessions so that
the PRR can be rapidly failed over as the result of the BFD session going down.
What scale of LSPs are you expecting this scenario to handle?
8) Sec 5.2.2: Given that the PRR will TEAR DOWN the LSP if it can't find a
matching bypass tunnel, it would be quite useful for the ingress to have
visibility as to the protection available. In RFC 4090, Sec 4.4 defines both
"local protection available" and "local protection in use" flags in the
IPv4/IPv6 sub-objects. Clearly, that isn't sufficient for the co-routed case
because the ingress needs to know also that "local upstream protection
available" and perhaps "local upstream protection in use".
9) Sec 5.2.3: " o The upstream PLR R4 starts sending the traffic flow of the
protected LSP over the restored link towards downstream PLR R3 and
forwarding the Path messages towards PRR R5 and stops sending the
traffic over the bypass tunnel.
o When upstream PLR R4 receives the protected LSP Path messages over
the restored link, if not already done, it starts sending Resv
messages and traffic flow over the restored link towards
downstream PLR R3 and forwarding the Path messages towards PRR R5
and stops sending them over the bypass tunnel."
In the referenced figures, R4 is NOT an upstream PLR; that is R5. R4 could
have forgotten all state associated with the bi-directional LSP. Please fix
the text to actually describe the behavior.
10) Sec 5.3: " Unidirectional link failures can result in the traffic flowing
on
asymmetric paths in the forward and reverse directions. In addition,
unidirectional link failures can cause RSVP soft-state timeout in the
control-plane in some cases. As an example, if the unidirectional
link failure is in the upstream direction (from R4 to R3 in Figures 1
and 2), the downstream PLR (node R3) can stop receiving the Resv
messages of the protected LSP from the upstream PLR (node R4 in
Figures 1 and 2) and this can cause RSVP soft-state timeout to occur
on the downstream PLR (node R3)."
Is the assumption that there is no IGP or BFD running on the link? If not, then
the IGP or BFD session will go down on the link first, making it unavailable to
RSVP-TE and should trigger the fast-reroute.
Also - given this issue, why does the upstream MP not start using the bypass
tunnel when receiving Resv through a bypass tunnel? There is no explanation in
the draft and there should be - to prevent incorrect "optimizations". Ideally,
the draft would specify something like MUST NOT or SHOULD NOT with explanation
- if that is the case.
11) Sec 7.1: The description for the BYPASS_ASSIGNMENT completely fails to be
clear as to whether the contents are for the bypass tunnel used by the node
inserting it into the RRO or whether the contents are a direction for the node
that receives it - based on the Node ID that is included.
a) Sec 5.2.2.1: The approach suggested here seems fairly intensive from a forwarding plane perspective. It would be very helpful to indicate the range of expected/desired time for the fail-over. b) Sec 5.2: This section is about node failures - but while the bypass tunnels are node-protecting, the failures discussed are only link. A brief example that describes the expected signaling for an actual node failure would be helpful.
What stops me from just providing a random IP address that I don't control in BYPASS_ASSIGNMENT and thus causing them to get spammed? I am assuming there are mechanisms to prevent them, but it's not immediately clear to me what those are, so they at minimum need to spelled out in security considerations. This section from RFC 4090 is not encouraging: This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RSVP] remain relevant. Note that the facility backup method requires that a PLR and its selected merge point trust RSVP messages received from each other.
You refer to Figure 2 on page 3 and it appears on page 12. Probably either you should move it up or make a copy.
draft-ietf-pce-pceps
I think that the document should explain why this does STARTTLS and not e.g another port (which would be more downgrade resistant) Obviously this is in addition to the DISCUSS held by EKR.
-3.4, step 2: "Peer validation always SHOULD include a check on whether the locally configured expected DNS name or IP address of the peer that is contacted matches its presented certificate." Why is that not a MUST? As it is, this need to at least discuss the risks involved if you don't check the identity of the peer cert (here or in the security considerations.)
Substantive:
- I share Warren's question about why you chose STARTTLS over a dedicated port,
especially since the 2nd to last paragraph in 3.2 goes out of its way to
mention that. What were the tradeoffs involved that made adding the additional
protocol machinery more attractive than allocating a port number?
- 3.2: "Implementations MUST support SHA-256 as defined by [SHS] as
the hash algorithm for the fingerprint."
Do you really intend "MUST support" (meaning you have to be able to handle
sha-256, but could allow other hashes) vs "MUST use"?
- 3.5: "Implementations
that want to support a wide variety of trust models SHOULD expose as
many details of the presented certificate to the administrator as possible
so that the trust model can be implemented by the administrator."
"as much as possible" is pretty vague for the a 2119 SHOULD. Since the
following sentences also include a SHOULD along with considerably more detail,
I suggest dropping the SHOULD in this sentence, and leaving the one in the
following sentence.
- 3.6: Is the exponential backoff requirement part of the procedures in 5440?
The wording suggests that it is not. If so, it needs elaboration here.
Editorial:
- 3.2, paragraph 8: s/"... PCE MUST responds with..."/ "...PCE MUST respond
with..."
- 3.4 : "Negotiation of mutual authentication is REQUIRED."
Does that mean that the peers must elect to use mutual authentication, or that
if they want to use it, they must agree to do so? (The pattern persists
throughout the section, but the meaning seems more obvious for some of the
others.)
-3.5, 2nd to last paragraph: Please don't use 2119 keywords to describe
pre-existing or external requirements. They should be reserved for the
authoritative specification of a given requirement.
-5, 2nd paragraph: The first sentence does not make sense.
I am very glad to see this document and I will be switching to "Yes" once we
discuss the following issues:
1)
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg |
|------- |
| \ StartTLS |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
|:::::::::TLS:::::::::| TLS Establishment
|:::::Establishment:::| Failure
| |
|<--------------------| Send Error-Type TBA2
| PCErr | Error-Value 3/4
| |
Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot
establish TLS
Firstly, I think you also need to demonstrate a case when the server end of TLS
is refusing to startTLS before trying TLS negotiation (e.g. if it doesn't have
certificate configured). In this case you need to send PCErr in the clear. I
think earlier text suggest that this case is possible.
Secondly, does the case depicted on this picture mean that TLS was negotiated
successfully, but TLS identities were not successfully verified? (I.e. the
PCErr is sent over the TLS layer). If TLS failed to negotiate, you don't have a
channel to send data on, as the other end will get confused. I think you just
have to close connection in such case.
So maybe you need 3 figures describing the above 3 cases.
2) In Section 3.4:
+ Implementations MAY allow the configuration of a set of
additional properties of the certificate to check for a
peer's authorization to communicate (e.g., a set of allowed
values in subjectAltName:URI or a set of allowed X509v3
Certificate Policies)
Can you give an example of what you expect to see in the subjectAltName:URI?
Your current text doesn't seem sufficient for interoperability.
I am agreeing with Ekr's DISCUSS points. Some of mine might be just a different
phrasing of his.
In Section 3.4. TLS Connection Establishment
* PCEPS implementations MUST, at a minimum, support negotiation
of the TLS_RSA_WITH_AES_128_GCM_SHA256, and SHOULD support
TLS_RSA_WITH_AES_256_GCM_SHA384 as well [RFC5288]. In
addition, PCEPS implementations MUST support negotiation of
the mandatory-to-implement ciphersuites required by the
versions of TLS that they support.
Should the last sentence apply starting from TLS 1.3 forward?
In Section 3.5:
[I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity
Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that MAY be
included in the OPEN Object. It contains a unique identifier for the
node that does not change during the lifetime of the PCEP speaker.
An implementation would thus expose the speaker entity identifier as
part of the X509v3 certificate, so that an implementation could use
Can you be a bit more specific, as this looks underspecified. Are you thinking
about using subject name or subject alt name for this (or either)?
this identifier for the peer identification trust model.
In the Security Considerations sections:
I think you should also talk about downgrade attacks here, e.g.
man-in-the-middle injecting error response in response to StartTLS command or
man-in-the-middle stripping StartTLS command.
* Section 3.2:
This seems to be overly broad and directly contradicts to what is required by
RFC5440.
A PCEP speaker receiving any other message apart from StartTLS, Open, or
PCErr as the first message, MUST treat it as an unexpected message
and reply with a PCErr message with Error-Type set to [TBA2 by IANA]
(PCEP StartTLS failure) and Error-value set to 2 (reception of any
other message apart from StartTLS, Open, or PCErr message), and MUST
close the TCP connection.
According to RFC5440, when a non-Open message is received the PCEP speaker is
required to send a PCErr message with Error-Type 1 ("PCEP session establishment
failure") and Error-value 1 ("reception of an invalid Open message or a non
Open message"). I think this text needs to be reworded to narrow down the scope
of this error.
* The fallback procedure after receiving the error code 4 needs to be
clarified. Is the response 4 remembered for future connections or is it only
limited to a single attempt immediately after the TLS connection establishment
failure. i.e. After falling back, does the client ever try to establish a
secure connection again?
* Section 3.2: This sentence needs to be reworded s/If a PCE that supports PCEPS connection/If a PCE supports PCEPS connection/
I support EKR's discuss points, especially the first. I'm a yes assuming that all the discuss points will be addressed, as I do think this work is important and am glad to see it. In addition to other comments, I don't think anyone else commented on the use of the word "privacy" instead of confidentiality in the security considerations section. That should be changed. Thank you.
1. This needs a cite to RFC 6125 to define how to do name validation.
2. You require TLS_RSA_WITH_AES_128_GCM_SHA256, but this is not
consistent with modern recommendations, which are for algorithms
that provide forward secrecy. You should be recommending
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with P-256, which is
consistent with the recommendations for TLS 1.3 (and UTA, IIRC).
3, It's clear to me how authentication of the PCE works in that
the PCC connects to it using a domain name or IP address and
therefore can check the PCC's certificate against that, but
it's not clear to me what the PCE does when the client connects?
Is it supposed to have a list of valid peers?
4. The error reporting mechanism you describe in S 3.2 is unusual:
After the exchange of StartTLS messages, if a PCEP speaker cannot
establish a TLS connection for some reason (e.g. the required
mechanisms for certificate revocation checking are not available), it
MUST return a PCErr message (in clear) with Error-Type set to [TBA2
by IANA] (PCEP StartTLS failure) and Error-value set to:
I am not aware of any other protocol that does this, and it's a bit
problematic because you either need to (a) require that you always
send a TLS alert so that the receiver knows that the next byte
is a PCE message or (b) specify some mechanism for demuxing PCE
and TLS. Even in the former category, many TLS stacks are greedy
about their IO, so they will read the alert + the PCE message and
then discard the message. Instead you should either:
(a) specify that you always send TLS alerts and don't send PCE
errors (TLS alerts are pretty rich)
(b) send any post-handshake alerts over the TLS connection.
Failing that, you need to provide detailed instructions about
how to make this work.
5. It seems like it would be a good idea to specify a pinning
mechanism so you could say "always do TLS in future". Is that
something that was discussed?
6. * TLS with X.509 certificates using certificate fingerprints:
Implementations MUST allow the configuration of a list of
trusted certificates, identified via fingerprint of the
Distinguished Encoding Rules (DER) encoded certificate octets.
Implementations MUST support SHA-256 as defined by [SHS] as
the hash algorithm for the fingerprint.
What does "trusted" mean here? I think it means "one I would accept as
a counterparty" rather than "can sign other certs". In any case, this
must be clear.
A bunch of other stuff is underspecified (see below).
This document needs a significant editorial pass. I found a number of
writing errors, e.g., "Securing via TLS of an existing PCEP session is
not permitted,"
S 1.
defining their application in depth. Moreover, [RFC6952] remarks the
importance of ensuring PCEP communication privacy, especially when
The term here is "confidentiality"
S 3.2.
The whole description of how you can race StartTLS iff you know you
are TLS only is really hard to understand until you get to the
diagrams. I would write something like:
The PCC initiates the use of TLS by sending a StartTLS message
The PCE agrees to the use of TLS by responding with its own
StartTLS message. If the PCE is configured to only do TLS, it
may send the StartTLS message immediately upon TCP connection
establishment; otherwise it MUST wait for the PCC's first
message to see whether it is an Open or StartTLS message.
S 3.4.
+ Implementations SHOULD indicate their trusted CAs. For TLS
1.2, this is done using [RFC5246], Section 7.4.4,
"certificate_authorities" (server side) and [RFC6066],
Section 6 "Trusted CA Indication" (client side).
Do common stacks do this? I know NSS does not.
To support TLS re-negotiation both peers MUST support the mechanism
described in [RFC5746]. Any attempt to initiate a TLS handshake to
establish new cryptographic parameters not aligned with [RFC5746]
SHALL be considered a TLS negotiation failure.
Is there a reason to allow renegotiation at all?
S 3.5
[I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity
Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that MAY be
included in the OPEN Object. It contains a unique identifier for the
node that does not change during the lifetime of the PCEP speaker.
An implementation would thus expose the speaker entity identifier as
part of the X509v3 certificate, so that an implementation could use
this identifier for the peer identification trust model.
This seems underspecified. Is there an OID assigned?
S 4.1.
DANE [RFC6698] defines a secure method to associate the certificate
that is obtained from a TLS server with a domain name using DNS,
i.e., using the TLSA DNS resource record (RR) to associate a TLS
server certificate or public key with the domain name where the
record is found, thus forming a "TLSA certificate association". The
DNS information needs to be protected by DNS Security (DNSSEC). A
PCC willing to apply DANE to verify server identity MUST conform to
the rules defined in section 4 of [RFC6698]. The server's domain
name must be authorized separately, as TLSA does not provide any
useful authorization guarantees.
This is also underspecified. Which DANE types are you suggesting you
use?
S 7.
Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. This specification does not
forbid the use of such ciphersuites, but administrators must weight
carefully the risk of relevant internal data leakage that can occur
in such a case, as explicitly stated by [RFC6952].
Why don't you forbid it?
One high level comment: As already mentioned by the gen-art review (Thanks Dale for the detailed review!), for me the text was for a long time while reading not clear on who starts the TLS negotiation. In think there is a statement missing that a speaker/PCE that supports PCEPS and receives a StartTLS message MUST reply with a StartTLS message and further the PCC MUST initiation the TLS after reception of a StartTLS message from the PCC. More minor/editorial comments: 1) There are two cases where the behavior of speakers that do not support PCEPS is specified, which is a bit non-sensical given that not support probably means it does not follow this spec: OLD "If the PCEP speaker that does not support PCEPS, receives a StartTLS message, it MUST behave according to the existing error mechanism described in section 6.2 of [RFC5440] (in case message is received prior to an Open message) or section 6.9 of [RFC5440] (for the case of reception of unknown message)." NEW "If the PCEP speaker that does not support PCEPS, receives a StartTLS message, it will behave according to the existing error mechanism described in section 6.2 of [RFC5440] (in case message is received prior to an Open message) or section 6.9 of [RFC5440] (for the case of reception of unknown message)." and OLD "A PCEP speaker that does not support PCEPS or has learned the peer willingness to reestablish session without TLS, can send the Open message directly, as per [RFC5440]." NEW "A PCEP speaker that does not support PCEPS sends the Open message directly, as per [RFC5440]. A PCEP speaker that supports PCEPS but has previously already learned the peer willingness to reestablish session without TLS, MAY send the Open message directly, as per [RFC5440]." 2) As already mentioned in the gen-art review, I also think there should be more text on what a host should do that uses StartTLS but gets an error back. This is defined previously in the document but given there is an own section here, I would just recommend to re-iterate there. In other words please add the proposed text! 3) Why is this a MUST? sec 8.1 "A PCE or PCC implementation MUST allow configuring the PCEP security via TLS capabilities as described in this document." Wouldn't a SHOULD be enough/better? Meaning that when PCEPS is implemented and turned on by default, I don't necessarily have to provide a knob to turn it off? 4) Also related to the previous point sec 8.2 "An implementation SHOULD allow the operator to configure the PCEPS capability and various TLS related parameters, ..." Probably this part of sentence should not be normative given this part is (differently) specified in the previous section.
draft-ietf-teas-gmpls-scsi
I do have a concern about error handling that should be pretty simple to fix. * Section 3 The document needs to specify the error handling on the receiver when the SCSI-TLV length is not a multiple of 4 octets. Are the following SCSI-TLVs processed or is everything ignored? Is there an error message sent?
- 6, paragraph 2: I think the draft needs to specify where IANA will put the registry, not leave it up to their discretion.
draft-ietf-mpls-rfc3107bis
I would like to discuss one issue before recommending approval of this document: In Section 2.1: The value field of the Multiple Labels Capability (shown in Figure 1) consists of one or more triples, where each triple consists of four octets. The first two octets of a triple specify an AFI value, the third octet specifies a SAFI value, and the fourth specifies a Count. If one of the triples is <AFI,SAFI,Count>, the Count is the maximum number of labels that the BGP speaker sending the Capability can process in a received UPDATE of the specified AFI/SAFI. I think lack of recommendations on the minimal supported Count value will result in lack of interoperability. What are the common Count values used by implementations?
In Section 2.3:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |Rsrv |S~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Label |Rsrv |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NLRI With Multiple Labels
- Length:
The Length field consists of a single octet. It specifies the
length in bits of the remainder of the NLRI field.
I would like to double check that my math is correct. With SAFI=128 and AFI=2,
assuming the prefix length of 192 bits, this will leave space for:
(255-192)/24 = 2.625. So this configuration only allows for 2 labels to be
included, right?
The security considerations section should at least mention that none of the tunnel methods provide encryption or authentication of those mentioned earlier in the document (Section 4: LSP, IP, GRE, & UDP). Although this isn't listed as a discuss, I'd appreciate the comment being addressed with an update to the text (1-2 sentences at most). Thank you.
Document: draft-ietf-mpls-rfc3107bis-02.txt
S 2.1
I note that you use 255 to mean "any number of labels" and 0 is marked
ignore. Is there a reason not to use 255 as a concrete number and 0
to mean "any number"? This is just for my information.
S 2.3.
Note that failure to set the S bit in the last label will make it
impossible to parse the NLRI correctly. See Section 3 paragraph j
of [RFC7606] for a discussion of error handling when the NLRI
cannot be parsed.
It would be helpful if you explicitly said that you parse this value
by reading labels one at a time until you get a non-zero S bit. It's
implicity, but having it be clear would be nice.
draft-ietf-urnbis-ns-reg-transition
I have a different take on Adam's discuss point. I don't think its appropriate for this draft to both obsolete 3044 and 3187 and make them historical. This draft doesn't replace them. And since IANA may have to deal with a mix of old and new templates for some transition period, it doesn't remove the need for them. Instead, I think it would make more sense for this draft to just change their status to historical, but not obsolete them. And also mention that in the abstract :-) .
The specification has not been properly vetted against the I-D Checklist. The draft header indicates that this document obsoletes RFC3044 and RFC3187, but the abstract doesn't mention this, which it should. Listing of obsoleted documents in the Abstract is specified by the ID-Checklist document (§3, 1.D, first bullet),
Major comment: Section 3 has suggested changes for RFC3188 for the next time it is revised. It's not clear, outside of institutional knowledge (which is a very fragile construct) how the indicated changes are going to be properly remembered when such revision takes place. Is there a good reason this document doesn't simply update RFC3188 by indicating an updated template directly? If this doesn't make sense, I would think that we need at least an erratum associated with RFC3188 that indicates the nature of update that needs to be performed. Minor comment: The document has at least nine places where external documents are mentioned but which are not, themselves, reference citations (e.g., "RFC 8141" rather than "[RFC8141]" in section 2). This will interact poorly with some RFC-related tooling. Please change these to references.
draft-ietf-httpbis-immutable
Cute.
I'm honestly surprised that we haven't already done this. Thanks for doing it now!
Presumably, the "Note to Readers" section should be removed prior to publication. Please either remove it, add a note to it that it should be removed, or add an RFC editor note to this effect. Trivial nits that aren't worth re-spinning the document before, but which you may wish to consider if you have any other reasons to revise it: - Put quotation marks around "immutable" in the abstract. - Replace "assures" with "insures" in the abstract (or rephase along the lines of "...assures the client that it never..."). - In the third paragraph of the Introduction, replace "Users that..." with "Users who..." - The cache control registry currently contains section numbers for every citation. Would update section 4 to indicate: "[this document, section 2]"
draft-nottingham-rfc5988bis
ART and others are more qualified to make useful determinations here, so I'll restrict myself to nits. :-P 1: The Note to Readers should have an "RFC Editor, please remove" tag. 2: Section 2: " A link can be viewed as a statement of the form "_link context_ has a _link relation type_ resource at _link target_, which has _targetattributes_". If possible, it would be really helpful to have an example here - this may be clear to those schooled in the arts, but I found this hard to parse, and required much flipping back and forth to understand.
- Since this seems to be the week for this recurring controversy: I agree with Mirja that the abstract should mention that this obsoletes 5988. 2.1.1.1 and 2.1.1.2 seem to entirely contain IANA considerations. It seems a bit strange to specify them here and reference them from the IANA section. (I can accept this as a stylistic choice, but it creates additional work for anyone who came to this draft primarily to learn the IANA bits.) - 2.1.1.1: "The expert(s) MAY define additional fields to be collected in the registry." How should they go about doing that? - 2.1.1.2: It seems like a mild abuse of the spirit of 2119 to put MUST and SHOULD requirements on the designated experts.
Processing comments: - The abstract should say that this document obsoletes RFC5988 - I don’t think we need to keep the pre-5378 disclaimer given Mark the only author of rfc5988 as well
It would be good to include a reference to RFC7525 in the security considerations section when talking about using TLS. Thanks.
Document: draft-nottingham-rfc5988bis-07.txt Link applications ought to consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP header fields. In particular, Link header fields that use the "anchor" parameter to associate a link's context with another resource are to be treated with due caution. I share Alan DeKok's concern here. Say I am a Web browser and I get a link with an anchor tag, what goes in Referer?
As compared to RFC5988, there are some non-backwards-compatible syntax changes in this new document that can hamper interoperability between new implementations and old ones. These changes should at least be called out explicitly, and guidance given to maximize chances of interop with RFC5988 implementations. See comments, below, for details.
Dropping the diff from RFC5988 in here for others' use:
https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/rfc/rfc5988.txt&url2=draft-nottingham-rfc5988bis-07
The document contains some modifications to IANA registration procedures,
including:
Note that relation types can be registered by third parties
(including the expert(s)), if the expert(s) determine that an
unregistered relation type is widely deployed and not likely to be
registered in a timely manner otherwise.
It's not clearly stated that this note overrides the MUST-strength normative
requirement to "reference a freely available, stable specification,"
although such is presumably the intention? If so, please make it very clear by
stating that this third-party registration process is exempted from the
normative requirement.
The new rules for syntax ('any "link-param" can be generated with values using
either the "token" or the "quoted-string" syntax') are not backwards-compatible
with RFC5988's definitions of anchor and hreflang (where the syntax of the
former requires quotes, and the syntax of the latter forbids them). I'm sure
this potential breakage was carefully evaluated, and the benefits were found to
outweigh the potential drawbacks; however, I'm surprised that the document does
not call out this situation explicitly. Please add text that at least points
out that these two parameters had previously been defined in a more strict
fashion, and maybe an indication that implementations wishing to maximize
interoperability should quote titles, and omit quotes from hreflang.
Along these lines, please update the associated ABNF to reflect this new syntax
rule; e.g., hreflang should be:
Language-Tag | <"> Language-Tag <">
Speaking of which -- we have ABNF for all parameters except "title" and
"title*". Was this omission intentional? It seems odd.
draft-bormann-hybi-ws-wk
Please see Dan Romascanu's OpsDir review for a typo / nit.
Document: draft-bormann-hybi-ws-wk-00.txt It has always been possible to form "ws" and "wss" URIs in such a way that they map to well-known HTTP(S) URIs when using the procedure in Section 4 of [RFC6455], so no new security considerations about this are created by now formally making the well-known URI mechanism available for "ws" and "wss", as well. However, with well-known URIs becoming available for the WebSocket protocol, applications that want to define well-known URI suffixes specifically for WebSocket use also need to consider whether the resources becoming available under the equivalent HTTP(S) URI formed by Section 4 of [RFC6455] pose any information disclosure or other security considerations. I'm not sure I am persuaded by this. The issue is that clients assume that these URIs have elevated privilege, so if it's not the case that WebSockets servers behave this way, we can't retroactively declare it. Can you explain in more detail why you think this is safe?
draft-turner-est-extensions
The above would have been less annoying if the XML had been wrapped in a <CODE BEGINS> / <CODE ENDS> tag. I'd encourage the author to look at the OpsDir review (https://datatracker.ietf.org/doc/review-turner-est-extensions-08-opsdir-telechat-wu-2017-06-19/) , which has some good comments, especially: # 3: while I don't think that quotes would help, I *do* find the forward slash in (S1) "simple enrollment with /simpleenroll, rekey/renew with /simplereenroll, etc." to be jarring - suggest "rekey or renew" instead. (some of the comments in the OpsDir review have already been addressed). Questions: Section 1.1. Definitions "clients that have a non-electronic air gap" -- I see that the "non-electronic" bit was added in a recent version, but I'm confused as to what it is trying to convey. What is an electronic vs non-electronic airgap? Was this to somehow address concerns about things like bypassing airgaps using audio or something? I'm sure that there was a reason for adding it, but it simply confused me. Nits: Section 1. Introduction. /firmware -- "... a mechanism for the infrastructure to inform the client that a firmware and software updates..." -- s/a// Section 4. Distribute CRLs and ARLs "Providing CRLs at the time of bootstrap would obviate the need for..." -- I'd suggest "Providing CRLs at the time of bootstrap obviates the need for..." Note: I previously had a DISCUSS position because the XML seemed to be incorrect. This appears to be a rendering artifact in different PDF viewers - for example, in the OS X Preview app, the opening <xsd:annotation> after the <xsd:complexType name="PAL"> doesn't render. This **seems** to be related to this specific document (but is sufficiently weird that I'm not sure), so it may be worth checking the final RFC Ed version for this issue.
I am generally fine with publishing this document, but there are several issues (mostly related to HTTP use) which need to be addressed before the document goes forward: 1) Every time you say in the document "HTTP 200 response code with no content" you should reference HTTP 204 response code <https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml#http-status-codes-1>, as it means no content. (We discussed this and proposed text work for me.) 2) As far as I know Content-Transfer-Encoding header field is not used in HTTP. You can use transfer coding or content coding instead (See <https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding>). But either way "base64" encoding is not defined in HTTP, so you can't use it. Mark Nottingham wrote about this: ------- CTE escapes into HTTP sometimes because of gateways to other protocols, or because of wrong-headed developers, but it has *NO* HTTP semantics. They can send the header all they want (after all, new headers can be introduced by anyone), but it's not interoperable. This was widely known enough that we took advice about it out of HTTPbis; see: https://tools.ietf.org/html/rfc2616#section-19.4.5 Looks like 7030 needs an errata, at a minimum. They don't want content-encoding (it's not terribly useful to introduce a base64 encoding on a binary-clean transport; they probably want to be using a content-type that dictates base64 encoding. Or just send the binary. ------- 3) In the IANA considerations: Package types MUST be paired with a media type. How? Does the list in Section 2.1.1 provide MIME types (it doesn't seem to)? (We discussed this and proposed text work for me.)
Please add normative references for the following (on first mention):
DN (Distinguished Name) - I would probably use one of LDAP RFCs for string
syntax or maybe RFC 5280.
2. Locate Available Packages
To get the /pal PC, the client and server need to mutually
authenticate each other with TLS and authorize each other. Clients
retrieve their PAL and processes it to determine the packages
available for it. Clients include the HTTP Accept header [RFC2616]
You should be pointing to [RFC7231] here.
2.1.3. PAL JSON Object
The following is an example PAL JSON object. The fields in the
object were discussed earlier in Sections 2.1 and 2.1.1.
[
{
"Type": 0003,
"Date": "2016-12-29T09:28:00Z",
"Size": 1234,
"Info": "https://www.example.com/.well-known/est/eecerts/1234"
}
I know this is a nit, but the above line is missing "," after "}"
{
"Type": 0003,
"Date": "2016-12-29T09:28:00Z",
"Size": 1234,
"Info": "https://www.example.com/.well-known/est/eecerts/9876"
}
]
8.3.2. Server-Side Key Generation Response
When rejecting a request, the server MUST specify either an HTTP 4xx
error or an HTTP 5xx error. If the content-type is not set, the
response data MUST be a plaintext human-readable error message.
Why not just require use "Content-Type: text/plain"?
Also, you might want to have a look at RFC 7807 and see if this is something
you want to use.
- 2.2/2.3: Is there any expectation that a server can provide the PAL in both XML and JSON?
1. The following requirement doesn't seem to do much on its own If a symmetric key package (which might be signed) or an encrypted key package (which might be signed before and after encryption) is digitally signed, the client MUST reject it if the digital signature does not validate back to an authorized TA. [S 5.1] The reason is that an attacker might just strip the signature and then it would be acceptable. So, I think it needs to somehow be paired with a way of knowing when things ought to be signed. There is another instance of this under asymmetric keys. 2. S 1.1. Package: An object that contains one or more content types. There are numerous types of packages: Asymmetric Keys, Symmetric Keys, Encrypted Keys, CRLs, Public Key Certificate Management, Firmware, Public Key Certificates, and TAMP packages. All of these packages are digitally signed and encapsulated in a CMS signed data [RFC5652][RFC6268] (except the public key certificates and CRLs that are already digitally signed); Signed using what key? 3. The reasoning for why some things need client auth and others do not is opaque to me. Like, why does firmware need client auth?
The abstract is kind of hard to follow. It would be useful to have a
more straightforward presentation. E.g.,
The EST (Enrollment over Secure Transport) protocol defined a Well-
Known URI (Uniform Resource Identifier): /.well-known/est along with
a number of other path components that clients use for PKI (Public Key
Infrastructure) services, namely certificate enrollment (e.g.,
/simpleenroll). This document defines a number of other PKI services
as additional path components, specifically....
The presentation of the PAL model is kind of hard to follow. In
particular, how am I supposed to know that I should provide a return
receipt for some operation. Do I:
(1) see the path in the PAL where I first discover the operation
(2) poll the PAL to see if it shows up with a receipt.
In general, I think a section on overall PAL usage would be helpful,
including covering polling, how to use date and time, etc. It would
also be helpful to indicate where the Info field can have an
indirection and where it cannot, as well as how to use the additional
PAL field (/pal).
S 1.
/tamp - To control the TAs in client TA databases, servers use
the /tamp PC to request that clients retrieve a TAMP query,
update, and adjust packages and clients use the /tamp/return PC
to return response, confirm, and error. The /tamp and
/tamp/return PCs are defined in Section 7.
Please provide a ref to TAMP.
S 1.6.
| Locate Available | N/A | Section 2.2 |
| Packages | application/xml or | Section 2.3 |
| | application/json | |
| | [RFC7303][RFC7159] | |
NIT: You should probably attach these citations to the relevant format.
The whole formatting of this table is pretty crazy, especially the TAMP
sections.
S 3.
The server need not authenticate or authorize the client for
distributing an EE certificate because the package contents is
NIT: "contents are"
S 5.1.
strength with the symmetric key being delivered to the client. The
cipher suite use MUST NOT have NULL encryption algorithm as this will
NIT: "suite used"
S 7.2.1.
As specified in [RFC5934], these content types should be signed. If
signed, a signed data encapsulates the TAMP content.
Is this a 2119 SHOULD?
S 8.3.1.
If you use pBE, how does the client know the password
One high level comment: The introduction of "/serverkeygen/return" actually seems to warrent an update of RFC7030 to me. One question: The shepherd write-up says it was presented in lamps but the chairs did not asks for adoption. Why? Questions on the IANA section: - Shouldn't pal be registered in the well-know URI registry? - Section 11.3 could be clearer. What's the name of the new registry and what fields are needed for registration? Should the media types be listed or how can this requirement be assessed: "Package types MUST be paired with a media type."?
draft-ietf-ippm-model-based-metrics
The abstract is overly long (long enough to run onto the second page.) That seems to detract from the purpose of an abstract. Can it be shortened to a paragraph or two?
High level comment: I still (compared to an earlier review I did during the first wg last call) think that the document could benefit from a mayor editorial pass that aims to remove redundancy (especially in section 8) and hopefully would lead to a much shorter document in the end. Especially the split between section 6, 7 and 8 is not always clear. It would actually be nice if the general model aspects and its applicability to one traffic class with the assumption that self-clocked, loss/CE-based congestion control is used would be separated more clearly. This would also help to separate generally reasoning from the test and evaluation instructions and make those more clear and understandable (in the sense that concrete implementation guidelines for both the tests and the evaluation seem quite hidden between all the other text at the moment). However, I understand that this is a lot of work and probably not appropriate at this state of processing. Processing comment: The references are not split into normative and informative. I guess most references including draft-ietf-tcpm-rack are informative. Indicating this clearly in two separate reference sections would also address the editor comment in 1.1 regarding draft-ietf-tcpm-rack. Various, mostly editorial comments: - The terminology mentions open loop. I would recommend to also note in the intro that these are open loop tests (compared to using TCP traffic directly). - ECN should be spelled out somewhere and RFC3168 should be referred (informatively). - It seems that the currently specified metrics and tests assume ack-clocked and loss/ECN-based congestion control. This might also worth stating in the intro given quic is experimenting with rate-based schemes. - Regarding the list at the end of section 4.1 on bursts: Shouldn't the initial window (which is usually today more than 4 packets) be mentioned additionally? - Network power could be defined in the terminology section. - It might also be useful to spell out more clearly in the intro that for these tests both endpoints (of the subpath under test) need to be under control of the tester. - As mentioned several times in the document, some of the tests are not intended for frequent monitoring tests as the high load can impact other traffic negatively. This should be re-stated clearly in the security considerations.
I saw one editorial nit in new text added to -11. If this gets fixed before the telechat, fine, and if not, it should be fixed afterwards. s/deigned/designed/
draft-ietf-httpbis-early-hints
I'll be a Yes after you help me figure this out, so this really is a request
for Discussion ...
In this text,
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
I see that the preload Links appear in both the 103 response and the 200
response.
(1) I'm not sure why that makes sense (HTTP still requires reliable transport,
no?), but
(2) more Discuss-worthy is that I'm not sure where the question of whether to
include the Early Hinted header fields is addressed.
Probably related, but since I can't figure out the answer to (2), I'm confused
about this, also - I'm assuming that the 200 response could have additional
Links that weren't included in the 103 response, but I don't see that written
down anywhere.
If this is an appeal to "be liberal in what you accept", that's an answer (and
I'd clear if it is), but I wonder if it is helpful to the implementer to make
this clearer than it was to me.
I have the same question that Mirja has, about Early Hints being a (possibly unintentional) amplification attack. I'm watching that conversation, but I suspect that one answer that I haven't seen go past yet, would be that clients know whether they have the resources to accept Early Hints; if they do, preloading resources that won't be used is wasteful but OK, while if they don't, they wouldn't be preloading resources anyway. If that's not true, I'd like to hear more. I have the same question Adam has, about how the server knows the client supports 103. I'll watch that conversation.
-2, example: (Related to Spencer's first comment): If the 103 links are required to also be in the 200 response, please state that explicitly somewhere. An example with multiple 103s might be helpful. - Note to Readers: I assume you intend this to be removed? if so, please do so or add a note to the RFC editor to do so.
One minor comment: Not sure if this should be part of the security consideration but isn't there also a higher risk of loading resources unnecessarily if the finale response turns out to not need these resources? Could that be even used somehow as an attack?
I had the same thoughts as Adam did about explicitly indicating support for this to avoid unnecessary traffic and guessing.
I don't understand this text: " HTTP/2 ([RFC7540]) server push can be used as a solution to this issue, but has its own limitations. The responses that can be pushed using HTTP/2 are limited to those belonging to the same origin. " Isn't this also a limitation of 103? Also, the HTTP spec says "The server MUST include a value in the :authority pseudo-header field for which the server is authoritative (see Section 10.1). A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a stream error (Section 5.4.2) of type PROTOCOL_ERROR." So I'm not sure that this restriction is correctly described
The document contains the following text: "a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly." This supposition does not indicate how a server might know this, and therefore implies that servers should engage in user-agent sniffing for guessing feature support. User-agent string sniffing is a well-known anti-pattern, and not one that we should be encouraging. My recommendation would be inserting an indication in the request to indicate client support of the 103 status code, which would serve the dual purpose of avoiding the issues discussed in the Security section as well as not taking up unnecessary bandwidth for the 103 itself when its contents will go unused.
draft-ietf-avtcore-aria-srtp
I agree with most of Ben Laurie's SecDir comments, and Ben's questions on SHA-1, but will leave it to the Sec ADs to evaluate.
I think it would be wise to add a paragraph to the security considerations to call out the dependency on SHA1. A mention of what would need to happen to migrate to newer hash functions could also be helpful.
+1 regarding SHA-1
Although this is not a discuss, I think updated text would be very helpful on the following two issues. I agree with the SecDir reviewer that there should be more text around the short tag length in the security considerations section. I don't see a response to that post though. For SHA-1, a reference to RFC6194 for the security considerations for SHA-1message digest algorithms would be helpful. Thank you!
This actually looks more like a document that we would rather typically publish by the ISE (as it is describing a method employed by one specific entity only). I do not object to it publication as informational and I do understand that this mostly due to the registration the in the MIKEY registry, however, i would like to note that IESG Approval would have been another option for this registration.