Last Call Review of draft-ietf-alto-server-discovery-08
review-ietf-alto-server-discovery-08-secdir-lc-tsou-2013-06-20-00

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