Roman Danyliw has entered the following ballot position for draft-ietf-capport-architecture-08: 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-capport-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Martin and Ben's DISCUSS positions. Thanks for laying out the architecture to explain the subsequent protocol drafts. A few areas of feedback: ** Section 2.1. Per “At this time we consider …”, to what is “at this time” referring (maybe this is referring to the WG scope)? This might not age well as currently framed. ** Section 2.2. The architecture doesn’t explicitly describe which component is responsibility for provisioning the user equipment sufficiently so it can access the IP network anywhere. I would have expected it to be the Provisioning Service. Section 2.1, 2.3 and 2.4 describe the role of these components in the architecture and their requirements. Section 2.2 does not. Instead it describes candidate technologies. It would be helpful to explicitly say. ** Section 2.3. Perhaps this is too pedantic, but should the obvious be explicitly called out: the user equipment should only be able to check it’s own captivity status? This would be some explicit notion of authorization. ** Section 2.3 Per “A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.”, is the caller the User Equipment, the web browser or the end user – does that distinction matter – does each layer need anything different? ** Section 3.2.1. Per “Each instance of User Equipment interacting with the Captive Network MUST be given an identifier that is unique among User Equipment interacting at that time.”, is “unique among user equipment interacting at that time” the same as saying “unique among the identifiers currently in use in the Captive Network”? It might be useful to frame this guidance within the scope of the previous definitions. ** Section 3.2.2. The acceptable workfactor for “hard” still isn’t clear here but I understand the difficulty of pinning it down while remaining flexible. ** Section 4. Does this section provide normative guidance? The introductory sentence suggests no by saying that this section describes “possible workflow[s]”. However, Section 4.3 uses a normative SHOULD. ** Section 4.2. Between step #2 and #3, did some kind of signaling happen to indicate that expiration is imminent, or did the UE keep state of some kind? Keeping state isn’t mentioned as a UE requirement in Section 2.1. Section 2.5. notes that a “signal might be generated when the end of a session is imminent”. ** Section 7. This section would benefit from a discussion of the privacy impacts of the implicit identifiers embedded into the architecture (e.g., re-identification) ** Section 7.1. Per “If a user decides to incorrectly trust an attacking network ….”, you have an on-path attacker so additional risks include traffic redirection to arbitrary destinations to server malicious payloads; traffic analysis and loss of confidentiality; inline traffic modification; etc. ** Section 7.2. Per “The solution described here assumes that when the User Equipment needs to trust the API …”, why is this conditional. Doesn’t the UE have to trust the API server? ** Section 7.3. In addition to integrity and confidentiality, is there an authenticity requirement? I ask because Section 2.1. noted that the UE “SHOULD [be] allow[ed] access to any services that User Equipment could need to contact to perform certificate validation.” _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
