Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft has issues that should be fixed before it moves forward. General ------- The word "suitable" appears 3-4 times in the document, but there is no definition of "suitable". In fact, there does not seem to be any evaluation of "suitability" in the procedures defined here. Either drop the word or define it and take account of the definition in the procedures. Abstract --------- Well done. Says what the document is about, sets the architectural context and limits the scope. No comment. 1. Introduction --------------- Again well done. Relates this document to other work done and in progress. No comment other than the one on "suitable" made above. 2. ALTO Server Discovery Procedure Overview ------------------------------------------- Provides the indicated overview. One substantive issue: not consistent with the detailed procedure given in Section 3. Please see below. You might also say that the procedure has to be performed for each interface, for each Address Family (AF) supported on that interface. Several nits: - neccessary, neccessarily -> necessary, necessarily - "yielded" might better be "configured" or "acquired" in paragraph 2 - whishes -> wishes in paragraph 3 3. ALTO Server Discovery Procedure Specification ------------------------------------------------- Definitely you should say here that the procedure has to be performed for each interface, for each Address Family (AF) supported on that interface. 3.1. Step 1: Retrieving the Domain Name 3.1.1. Step 1, Option 1: User input ------------------------------------ Begins by giving the motivation for user override, then defines an user input procedure which falls back to DHCP. Comment: That appears to contradict the summary in Section 2, which says that DHCP is the primary means of acquiring the domain name. If Section 2 is correct, it would seem logical to present what is now in Section 3.1.2 first, followed by the current contents of Section 3.1.1. Furthermore, after the example of user override in the user input section, perhaps say that implementations MUST allow for user input if the DHCP option fails, and SHOULD allow user input to override the DHCP. On the other hand, further down it appears that the authors have assumed that if the user provides the domain name, it applies to all interface-AF combinations. Is this a reasonable assumption? If so, the current order of presentation is reasonable but 3.1.1 should explicitly state this assumption. 3.1.2. Step 1, Option 2: DHCP ------------------------------ Second para introduces the relevant DHCPv4 and DHCPv6 options. Third para provides details with normative language. No comment. 3.2. Step 2: U-NAPTR Resolution -------------------------------- Reviews the result of the first step, gives details of the U_NAPTR lookup procedure, gives an example, and discusses failure cases. Comment: the statement that an HTTPS: result is preferred is made in the example (third paragraph). That statement should be part of the normative procedural description in the second paragraph. Comment: the last sentence of the final paragraph seems slightly ambiguous. If the phrase "lookup that has failed" is expanded to "lookup of a domain name-interface-AF combination that has failed" capture the authors' intention? Editorial: the third paragraph should begin with the statement: "Here is an example." 4. Deployment Considerations 4.1. Issues with Home Gateways ------------------------------- Notes that the home gateway could fail to pass the necessary DHCP options to the host because it fails to understand them. Notes further that the home gateway could pass a local DNS name to the host in place of the name returned by DHCP. In this case the procedure will fail unless the home gateway itself resolves the NAPTR lookup correctly. Editorial: issues -> issue in the first line of the last paragraph. 4.2. Issues with Multihoming, Mobility and Changing IP Addresses ----------------------------------------------------------------- Notes that: - manual entry could give undesirable results in the case of mobility - DHCP usage applies per interface-AF combination - Alto server(s) used should (no normative text) be that/those applicable to the interface-AF combination selected - a change of address on an interface invalidates any prior choice of Alto server(s) for that interface-AF combination - a server good for one interface may not be good for another - DHCP generally not available for VPNs and mobile IP, hence manual configuration (of the domain of the VPN gateway or Home Agent) will be required. Comment: The first paragraph appears to assume that manual entry provides a single domain name that applies to all interface-AF combinations. Is this intended? (See also comment to Section 3.1.1 above.) Comment: The point about DHCP per interface-AF combination should appear earlier, see comments to Section 2 and 3 above. Editorial: second paragraph, familly (line 2) and familiy (line 4) -> family 5. IANA Considerations ----------------------- Registers U-NAPTR application service tag. No comment. 6. Security Considerations --------------------------- No current content. Comment: suggest that this section say that implementers and operators must understand the security considerations presented in Section 14 of [I-D.ietf-alto-protocol]. Further, the present section responds to the requirement on the discovery process implied by Section 14.1.3 of [I-D.ietf-alto-protocol]. 6.1. General Security Considerations ------------------------------------- Describes two failure modes: inability to get a URI at all, and getting a URI that points to a poor choice of Alto server or one containing the wrong information either by misconfiguration or by malicious intent. In the latter case, advises operator to watch for undesirable traffic patterns or user complaints of poor performance and terminate Alto service if they occur. Comment: this section presents no discussion of the mechanisms by which an attacker may interfere with the Alto service. Without identifying potential mechanisms, it is not possible to suggest mitigating measures. To focus their discussion, the authors might wish to consider the organization of discussion in [I-D.ietf-alto-protocol]: "Risk Scenarios" - "Protection Strategies" - "Limitations". 6.2. Security Considerations for U-NAPTR ----------------------------------------- Notes that "interception" of messages not an issue because the URI of the Alto server in a domain is generally well known. Identifies three specific attacks: falsified input domain name, DNS alteration, and actual server impersonation. Suggests the use of DNSSEC to thwart DNS alteration and provides some discussion of the use of https: to authenticate the server. Refers to RFC 5986 for the rest. Comment: what the opening paragraph means to say is probably that message confidentiality is unnecessary. Interception and modification or blocking of messages would constitute attacks that you might discuss. Comment: once the discussion in Section 6.1 has been properly focussed, the authors may need to reorganize the discussion to eliminate redundancy between 6.1 and 6.2. Comment: most of Section 6.2 is copied from the Security Considerations section of RFC 5986. This is reasonable, since the contexts are very similar. There is one real difference, in that, rather than suggesting administrative constraints on the domain name used for the Alto server, the present document calls for the use of DNSSEC to ensure the validity of the returned URI. Here is a suggestion for a more direct presentation of Section 6.2: - Section 5 of RFC 5986 is generally applicable to the present document, with the substitution of the Alto server for the Location Information Server (LIS). - That section identifies three attacks: falsified input domain name, DNS alteration, and actual server impersonation, and suggests mitigating measures for each. Implementors and operators should read that section for details. - Rather than using the input domain provided by the user or DHCP in the https: validation procedure (which implies administrative constraints on the domain name used for the Alto server), the present document recommends the use of DNSSEC to assure the validity of the returned URI, followed by the use of the domain contained in the URI in the https: validation procedure. Thank you, Tina