[alto] Roman Danyliw's No Objection on draft-ietf-alto-oam-yang-17: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-oam-yang-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/ -- COMMENT: -- Thank you to Rich Salz for the SECDIR review. Thank you for addressed by COMMENT and DISCUSS feedback. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's Discuss on draft-ietf-alto-oam-yang-16: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-oam-yang-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/ -- DISCUSS: -- Per -15 ballot review: ** Section 8. Per the guidance on writeable data, aren’t significant parts of alto-server/listen sensitive as one could alter the stored keys for the server or client; or the username/password combinations (in http-server-parameters)? ** Section 8. Per the guidance about readable data: -- isn’t tls-server-parameters sensitive since it could contain raw private keys (e.g., ks:inline-or-keystore-symmetric-key-grouping)? -- Would it be best practice to be able to read all of the authorized users? Thanks for the response at https://mailarchive.ietf.org/arch/msg/alto/tD88zktK20QDBIbd-jbGt5JJDLc/ > Yes, some groupings in alto-server/listen are also sensitive. But they are > defined in other RFCs, thus the security considerations in those RFCs also > apply to them. This described approach is inconsistent with my observation on how the YANG security template is used. If there is a path which has security considerations, the issues are typically highlighted regardless of whether there is reuse. Setting aside that this is a YANG module, my experience with any protocol document is that if there is a mechanism reused by reference and it introduces a relevant security dependency, it would have been cited in the Security Considerations as applicable. Neither of these approach appear to be taken here. Is there a reason why not? -- COMMENT: -- Thank you to Rich Salz for the SECDIR review. Thank you for addressed by COMMENT and DISCUSS feedback. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's No Objection on draft-ietf-alto-new-transport-21: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-new-transport-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/ -- COMMENT: -- Thank you to Donald Eastlake for the SECDIR review. Thanks for addressing my DISCUSS feedback. ** Section 6.2. Editorial. New text was added clarifying text to prescribe that TIPS view URI must not be reused. I would recommend being a clearer on this language. OLD A server MUST NOT use a URI for different TIPS views, either for different resources or different request bodies to the same resource. NEW A server MUST NOT use the same URI for different TIPS views, either for different resources or different request bodies to the same resource. ** Section 9. The security considerations (Section 15 of [RFC7285]) of the base protocol fully apply to this extension. For example, the same authenticity and integrity considerations (Section 15.1 of [RFC7285]) still fully apply; Since ALTO TIPS is a new protocol mechanism is it possible to improve on the TLS guidance in Section 8.3.5 of RFC7295 (from circa 2014)? Specifically, can RFC9325 be mandated? ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's Discuss on draft-ietf-alto-oam-yang-15: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for
draft-ietf-alto-oam-yang-15: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-oam-yang/
--
DISCUSS:
--
(There were a number of YANG references to chase down. Please correct my read
of the YANG model if I have misunderstood.)
** Implementing mutual TLS/client side certificates (per Section 8.3.5 of
RFC7285) appears to need more guidance. Client EE certificates and client CAs
can be specified by the tls:tls-server-group in
alto/server-listen-stack/https/tls-server-parameters. However, it appears to
me that there isn’t any way then to later reference them in the
alto-server/auth-client section. When doing username and password
authentication via http-server-parameters/client-authentication, there is a
common user-id field shared with auth-client/https-auth-client.
** Section 5.4.3. It appears that there is an http-auth-client for both http
and https. Is this suggesting that it is possible to have authenticated users
over unencrypted HTTP. How does that work securely? Is this related to
Section 8’s “The ietf-alto supports an HTTP listen mode to cover cases where
the ALTO server stack does not handle the TLS termination itself, but is
handled by a separate component.” If so, what is the residual risk of this
approach?
** Section 8. Per the guidance on writeable data, aren’t significant parts of
alto-server/listen sensitive as one could alter the stored keys for the server
or client; or the username/password combinations (in http-server-parameters)?
** Section 8. Per the guidance about readable data:
-- isn’t tls-server-parameters sensitive since it could contain raw private
keys (e.g., ks:inline-or-keystore-symmetric-key-grouping)?
-- Would it be best practice to be able to read all of the authorized users?
--
COMMENT:
--
Thank you to Rich Salz for the SECDIR review.
** Section A.5. Per the example:
"client-authentication": {
"users": {
"user": [
{
"user-id": "alice",
"basic": {
"user-id": "alice",
"password": "$0$p8ssw0rd"
}
Isn’t the password supposed to be hashed?
draft-ietf-netconf-http-client-server says password is of type
ianach:crypt-hash.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-new-transport-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/ -- DISCUSS: -- ** Section 6.2. Construction of the “tips-view-uri”. -- Under what circumstances would it be appropriate to use http (instead of https) for the tips-view-uri for this new protocol mechanism? Why is http needed? Could https be the only option? I appreciate that there is history of an http URL from RFC7285 published in 2014, but has field experience continue to dictate a need for this insecure approach for an entirely new service? If it is needed would there be a away to express a preference for secure transport? -- Is there any underlying assumption in how “tips-view-path” is constructed? I asked because Section 9.3 says “An outside party that can read the TIPS response or that can observe TIPS requests can obtain the TIPS view URI and use that to send fraudulent ‘DELETE’ requests thus disabling the service for the valid ALTO client. This can be avoided by encrypting the requests and responses (Section 15 of [RFC7285]).” Observing the tips-view-uri is one way to spoof the URI, but what if it could be guessed? Is there an assumption that a unguessable random string is part of the path? As far as I can find, no text explicitly says that, although the examples imply it. If the string is guessable being encrypted doesn’t help but using some kind of authentication would. -- COMMENT: -- Thank you to Donald Eastlake for the SECDIR review. ** Section 6.3. The example in Figure 10 describes Basic Auth. Section 8.3.5 of RFC7295 notes that Digest Auth is MTI. Recommend using that instead. ** Section 9. The security considerations (Section 15 of [RFC7285]) of the base protocol fully apply to this extension. For example, the same authenticity and integrity considerations (Section 15.1 of [RFC7285]) still fully apply; Since ALTO TIPS is a new protocol mechanism is it possible to improve on the TLS guidance in Section 8.3.5 of RFC7295 (from circa 2014)? Specifically, can RFC9325 be mandated? ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's No Objection on draft-ietf-alto-cost-mode-03: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-cost-mode-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/ -- COMMENT: -- Thank you to Stephen Farrell for the SECDIR review. Section 4 specifies an assignment policy of “IETF Review.” To double-check, you also do not want a designated expert too? ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-20: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-path-vector-20: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ -- DISCUSS: -- (Updated ballot to make the remaining issues clear) Thanks for the update in -20 and in particular all of the new language in the Security considerations to discuss applicability and obfuscation procedures. In these edits in response to the earlier DISCUSS text, the following sentence was introduced into Section 11: For settings where the ALTO server and client are not in the same trust domain, Digital Right Management (DRM) techniques and legal contracts protecting the sensitive Path Vector information MUST be applied. It appears to be trying to provide guidance on how to ensure that only the expected ALTO clients get the sensitive path information in the case where the server and clients are in different trust domains. This new language contains normative guidance to using DRM techniques. Given this is a normative “MUST”, the specifics of “DRM techniques” is under-specified. Independent of that, DRM techniques I quickly think of provides object security (i.e., embedding a security envelope of some form directly in the data it is trying to protect). How would that mesh with the specified format for the path information in this document? -- COMMENT: -- Thanks to Samuel Weiler for the SECDIR review. Thanks for addressing my COMMENTs. Previous DISCUSS point below == Thanks for documenting the increased risk of exposing sensitive topology information and the potentially of this data being exploited for a highly targeted DoS attack in Section 11. While this significant problem is documented, the mitigation for this fundamental issue is underspecified. The security of this extension is predicated on the ANE obfuscation procedures, but those specifics are not provided. In my review, there doesn’t appear to be wide operational usage or implementations of this extension to inform these obfuscation procedures. Furthermore, it appears that these procedures remain an open research question. I appreciate the helpful references to the academic papers in Section 11 ([NOVA], [RESA][ MERCATOR]) but their practical applicability to the generic capability provided by this extension appears to be difficulty to align and be caveated. For example, [RESA] and [MERCATOR] made what appear to be significant assumptions on their approaches, “In this paper, we assume a semi-honest security model, i.e., the aggregator and all member networks will not deviate from the security protocol, but merely try to gather information during the execution of the protocol”. I believe this document needs to be provide a stronger applicability statement constraining where it can be fielded and what assumptions are made about the trust models. Additionally, given the uncertainty on the generic feasibility of obfuscation, this document should be published as experimental. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's No Objection on draft-ietf-alto-cdni-request-routing-alto-18: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-cdni-request-routing-alto-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/ -- COMMENT: -- Thanks to Klaas Wierenga for the SECDIR review. Thanks for addressing my DISCUSS point ** Section 8. For authenticity and integrity of ALTO information, an attacker may disguise itself as an ALTO server for a dCDN, and provide false capabilities and footprints to a uCDN using the CDNI Advertisement service. -- I don’t follow the intent of the first clause. Why is an _attacker_ concerned with the authenticity and integrity of the ALTO information? -- What role can TLS, an associated server certificate (for the dCDN) and configured knowledge of this certificate at the uCDN mitigate some of this risk? Shouldn’t the uCDNs only be communicating with a collection of known dCDNs with which it has some out-of-band negotiated arrangement? ** Section 8. For availability of ALTO services, an attacker may conduct service degradation attacks using services defined in this document to disable ALTO services of a network. Again, operating under the assumption that the dCDN (ALTO Server) would only be working with a known (prearranged) set of uCDNs and they would have authenticated somehow (per the DISCUSS), couldn’t repeated requested be rate limited and after attribution, filtered to minimize impact? ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's Discuss on draft-ietf-alto-cdni-request-routing-alto-17: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-cdni-request-routing-alto-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/ -- DISCUSS: -- The security consideration is silent on how to handle client (uCDN) authentication for this specific CDN use case. Hence, the default guidance from Section 15.13.2 of RFC7285 seems to apply -- that HTTP Digest Authentication or TLS client authentication could be used. If I understand the use case right, it seems like the uCDNs and dCDNs should know about each other, and there wouldn’t be an unreasonably large number of them to prevent credentials existing for peers. Is there a reason why there isn’t a normative guidance requiring some kind of peer authentication given this narrow use case? If not, why is ok given the significance of this ALTO data in FCI model. -- COMMENT: -- Thanks to Klaas Wierenga for the SECDIR review. ** Abstract. Typo? RFC 8008 defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is specified Shouldn’t this read, “but the exact protocol is _NOT_ specified”? ** Section 8. For authenticity and integrity of ALTO information, an attacker may disguise itself as an ALTO server for a dCDN, and provide false capabilities and footprints to a uCDN using the CDNI Advertisement service. -- I don’t follow the intent of the first clause. Why is an _attacker_ concerned with the authenticity and integrity of the ALTO information? -- What role can TLS, an associated server certificate (for the dCDN) and configured knowledge of this certificate at the uCDN mitigate some of this risk? Shouldn’t the uCDNs only be communicating with a collection of known dCDNs with which it has some out-of-band negotiated arrangement? ** Section 8. For availability of ALTO services, an attacker may conduct service degradation attacks using services defined in this document to disable ALTO services of a network. Again, operating under the assumption that the dCDN (ALTO Server) would only be working with a known (prearranged) set of uCDNs and they would have authenticated somehow (per the DISCUSS), couldn’t repeated requested be rate limited and after attribution, filtered to minimize impact? ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's No Objection on draft-ietf-alto-unified-props-new-21: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-unified-props-new-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ -- COMMENT: -- Thank you to Paul Wouters for the SECDIR review. ** Section 3.1. This section provides a list of examples of entities, but doesn’t cite a few of them. For example: -- as = should be [I-D.ietf-alto-cdni-request-routing-alto] -- country = should be [I-D.ietf-alto-cdni-request-routing-alto] -- network flow = ? -- routing element = ? ** Section 3.2.1 An entity domain type MUST be registered at the IANA, as specified in section Section 12.2.2 and similarly to an ALTO address type. Per the text in Section 12.2.2, it doesn’t appear that a binding to an ALTO address type is required. For example neither pid or priv have an “ALTO address type”. ** Section 4.6 Besides, it is also necessary to inform a Client about which associations of specific resources and entity domain types are allowed, because it is not possible to prevent a Server from exposing inappropriate associations. An informed Client will just ignore inappropriate associations exposed by a Server and avoid error-prone transactions with the Server. -- Editorial, s/Besides, it is also/It is also/ -- What does it mean that it’s “necessary to inform a Client about which associations”? I was under the impression that this section was documenting the IRD capability behavior which is triggered by the client. If so, the client “is asking” in this interaction model rather than being “informed”. -- What is meant by “it is not possible to prevent a Server from exposing inappropriate associations”? Is it envisioned that the Server might respond with an associations which isn’t self-consistent with another part of the property map? ** Section 4.6 For example, the association "costmap3.pid" is not allowed for the following reason: although a cost map exposes PID identifiers, it does not define the set of addresses included in this PID. I don’t follow what this example is trying to demonstrate – in that, how is it related to the what’s supported in the IRD capability. From the explanation, it appears that a costmap and a pid can never be mixed. No query to an IRD would be needed to know that. ** Section 5.1.1. Would “_”, “-“, “__--" be considered valid EntityDomainTypes? If so, is that desirable? (it's perfectly reasonable to say "absolutely") ** Section 5.1.1 For an endpoint domain type identifier with the "priv:" prefix, an additional string (e.g., company identifier or random string) MUST follow (i.e., "priv:" only is not a valid entity domain type identifier) to reduce potential collisions. I found this language confusing. “priv:” is not a domain type identifier. It’s only a prefix to the domain type identifier. It couldn’t be a domain type identifier because the colon is not permitted in things of type EntityDomainType. Is this text effectively saying that EntityDomainType has to be a non-zero length string, which should be true whether “priv:” is used or not. If so, I’d recommend being clearer. ** Section 5.2.1. -- What’s the thinking on EntityPropertyType having a colon, but EntityDomainType (Section 5.1.1) cannot? -- Could “:” or “_::-“ be a valid EntityPropertyType? If so, is that desirable? (it's perfectly reasonable to say "absolutely") ===[ Nits ** Section 1. Editorial At first, a map of endpoint properties might seem impractical, because it could require enumerating the property value for every possible endpoint. However, in practice, the number of endpoint addresses involved by an ALTO server can be quite large. The “However, in practice ” part doesn’t follow from the previous sentence. s/However, in practice, the number/The number/ ** Section 3.3. Editorial. s/Likewise, a same/Likewise, the same/ ** Section 5.1.3. Editorial. OLD The format of the second part of an entity identifier depends on the entity domain type, and MUST be specified when defining a new entity domain type and registering it with the IANA. NEW The format of the second part of an entity identifier, DomainTypeSpecificEntityID, depends on the entity domain type, and MUST be specified when defining a new entity domain type and registering it with the IANA. ** Section 8.6. Typo. s/contanaing/containing/ ** Section 9.3. Typo. s/is is/is/ **
[alto] Roman Danyliw's No Objection on draft-ietf-alto-performance-metrics-20: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-performance-metrics-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/ -- COMMENT: -- Thanks to Vincent Roca for the SECDIR review. ** Section 1. An ALTO server may provide only a subset of the metrics described in this document. For example, those that are subject to privacy concerns should not be provided to unauthorized ALTO clients. Is this generic caution, or are any of the mentioned metrics considered privacy sensitive in some way? ** Section 2.1. Editorial. s/, and “sla”/, “sla”/ ** Examples 1 – 7 all have a their “Content-Length” set to “TBA”. Consider populating it with the real length of each of the examples. ** Nit. Example 7 (in Section 4.2.4) comes earlier than Example 6 (in Section 4.3.3) ** Section 6. In the spirit of inclusively, please rephrase “man-in-the-middle (MITM) attacks” ** Additional Security Considerations. It appears that in cases of an “sla” and certain “estimation” cost-estimates, it is recommended for a URI to be provided via the parameters field to point to additional information. -- is there any further guidance that can be provided on how this URI can be secured. Perhaps, requiring https? -- additional, I would recommend guidance to this effect (please polish the language on what exact ALTO fields are in question): When ALTO clients process the URIs in the “link” field provided in the “parameters” field of select “sla” and “estimation” cost-estimate metrics, they should heed the risks outlined in Section 7 of RFC3986. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's Discuss on draft-ietf-alto-path-vector-19: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-path-vector-19: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/ -- DISCUSS: -- Thanks for documenting the increased risk of exposing sensitive topology information and the potentially of this data being exploited for a highly targeted DoS attack in Section 11. While this significant problem is documented, the mitigation for this fundamental issue is underspecified. The security of this extension is predicated on the ANE obfuscation procedures, but those specifics are not provided. In my review, there doesn’t appear to be wide operational usage or implementations of this extension to inform these obfuscation procedures. Furthermore, it appears that these procedures remain an open research question. I appreciate the helpful references to the academic papers in Section 11 ([NOVA], [RESA][ MERCATOR]) but their practical applicability to the generic capability provided by this extension appears to be difficulty to align and be caveated. For example, [RESA] and [MERCATOR] made what appear to be significant assumptions on their approaches, “In this paper, we assume a semi-honest security model, i.e., the aggregator and all member networks will not deviate from the security protocol, but merely try to gather information during the execution of the protocol”. I believe this document needs to be provide a stronger applicability statement constraining where it can be fielded and what assumptions are made about the trust models. Additionally, given the uncertainty on the generic feasibility of obfuscation, this document should be published as experimental. -- COMMENT: -- Thanks to Samuel Weiler for the SECDIR review. ** Overstatement of security properties. Section 1. For better confidentiality, this document aims to minimize information exposure. Section 5.1.2. By design, ANEs are ephemeral and not to be used in further requests to other ALTO resources. More precisely, the corresponding ANE names are no longer valid beyond the scope of the Path Vector response or the incremental update stream for a Path Vector request. This has several benefits including better privacy of the ISPs and more flexible ANE computation. The text in both of these sections reads to strongly. This document defines the ANEs which in fact provides more detailed network information but provides no normative operational guidance or protocol-based protections to minimize (obfuscate) this information. These claims seem to rest of practices which are out of scope of this document ** Section 5.1.2. Editorial This has several benefits including better privacy of the ISPs and more flexible ANE computation. Words are missing from this sentence – “better privacy of the ISPs” what? ** Section 5.1.3. Resource-constrained ALTO clients may benefit from the filtering of Path Vector query results at the ALTO server ... Can you describe the use case of these “resource-constrained ALTO clients” as nothing about the use cases in Section 4.2 suggested that the clients were constrained. ** Section 5.2. To be pedantic on what’s strictly in C++: OLD For example, in programming languages such as C++, a Path Vector will have the type of JSONArray. NEW For example, in programming languages such as C++ where there existed a JSON array type named JSONArray, a Path Vector will have the type of JSONArray. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's No Objection on draft-ietf-alto-incr-update-sse-20: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-incr-update-sse-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/ -- COMMENT: -- ** Section 7.1. “To prevent an attacker from forging a stream control URI and sending bogus requests to disrupt other update streams, stream control URIs SHOULD contain sufficient random redundancy to make it difficult to guess valid URIs.” -- This approach provides no protection against an on-path attacker if https isn’t used (Section 8.3.5 of RFC7285 only says that “ALTO server implementations … MUST support the ‘https’ URI scheme”, not MUST use). -- The words “random redundancy” wasn’t clear to me, but contextually, I understood the intent. ** Section 9.1. Per “For stable resources with minor changes, the update stream server may choose to send incremental changes; for resources that frequently change, the update stream server may choose to send a full replacement after a while.”, it isn’t clear what guidance this is providing as both statements are “mays”. The server always has the ability to choose the approach of returning the updates. ** Section 9.1. Per “Other JSON-based incremental change format may be introduced in the future”, this statement doesn’t seem to have value in an archival format without citation. Section 10. With the addition of the URI parameter for the stream control service, the attack surface described in Section 15.1.1 of RFC7285 gets larger (as this could cause redirection to a host of choice) – same mitigation though (use TLS). ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Roman Danyliw's No Objection on draft-ietf-alto-cost-calendar-19: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-alto-cost-calendar-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ -- COMMENT: -- A few minor comments: Section 1.1. The role of the text describing the SENSE project isn’t clear. I’m not sure it will age will when in an RFC Section 3. Thanks for providing an overview with the section. Given that this section is non-normative, how should the implementers use the text with RFC2119 words -- is it there just for emphasis? Section 4.1. Per ‘Attribute "cost-type-names" provides a better readability to the Calendar attributes specified …”, could you please clarify “a better readability”. Section 4.3. Nit. s/mode,to/mode, to/ ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
