Subject: [secdir] Secdir review of draft-ietf-mmusic-rfc2326bis-34

From: "Chris Lonvick (clonvick)" <[email-masked]>
Date: Thu, 6 Jun 2013 16:37:26 +0000

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 is a lengthy document and I did not have time to fully review it.  I did review the Security Considerations section and found it to be well written and thorough.  I found no problems there and consider that it appropriately covers the concepts in the document.

Thanks,
Chris

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 7 Jun 2013 08:18:36 +0200

Hi Chris,

Did you review Section 19 - Security Framework and section C.1.4 which
are the two major sections which defines usage of security mechanisms?

Thanks,

Magnus

On 2013-06-06 18:37, Chris Lonvick (clonvick) wrote:
> 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 is a lengthy document and I did not have time to fully review
> it.  I did review the Security Considerations section and found it to
> be well written and thorough.  I found no problems there and consider
> that it appropriately covers the concepts in the document.
> 
> Thanks, Chris
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Chris Lonvick (clonvick)" <[email-masked]>
Date: Fri, 7 Jun 2013 15:25:36 +0000

Hi Magnus,

Unfortunately I did not review those sections. My travel with the day job lately has prevented me from doing that. I did want to get a review in before the deadline and what I did was all that I could accomplish right now. 

I do have a long-ish flight coming up in a few days. If it would help, I could review those sections and have my notes out by next Wednesday or Thursday. Let me know. 

Best regards,
Chris

Sent from my phone.

---

From: "Chris Lonvick (clonvick)" <[email-masked]>
Date: Sun, 9 Jun 2013 22:52:51 +0000

Hi All,

I looked over those sections on my long-ish flight and have written up some notes while I'm waiting for my very much delayed final leg back home.

Without a thorough reading of the entire document, I'll say that I understand the intentions of Appendix C.1.4, and Section 19, but havn't fully wrapped my head around it.  I'll also say that I'm not well versed in MIKEY.  Since it stood out, I also looked at Appendix G.  Nothing stood out as being insecure and I'll say again that most of the documentation is very well done.

Below are some nits:

Appendix G

Current:
   This section provides anyone intending to define how to transport of
   RTSP messages over a unreliable transport protocol with some
   information learned by the attempt in RFC 2326 [RFC2326].  RFC 2326
   defined both an URI scheme and some basic functionality for transport
   of RTSP messages over UDP, however, it was not sufficient for
   reliable usage and successful interoperability.

   The RTSP scheme defined for unreliable transport of RTSP messages was
   "rtspu".  It has been reserved by this specification as at least one
   commercial implementation exists, thus avoiding any collisions in the
   name space.
   
   The following considerations should exist for operation of RTSP over
   an unreliable transport protocol:
   
Proposed:
   This appendix provides guidance for those who want to implement RTSP messages over unreliable transports as has been defined in RFC 2326 [RFC2326].  RFC 2326 defined the "rtspu" scheme and provided some basic information for the transport of RTSP messages over UDP.  The information is being provided here as there has been at at least one commercial implementation and compatibility with that should be maintained.
   
   The following points should be considered for an interoperable implementation:

CML> Throughout the document, I found an assortment of "an URI" and "a URI".  Please pick one and be consistent.  :-)

CML> Do you want to say something about using rtspu is NOT RECOMMENDED in the Security Considerations section?

Best regards,
Chris
________________________________________
From: Chris Lonvick (clonvick)
Sent: Friday, June 07, 2013 10:25 AM
To: Magnus Westerlund
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir review of draft-ietf-mmusic-rfc2326bis-34

Hi Magnus,

Best regards,
Chris

Sent from my phone.

---

From: Tina TSOU <[email-masked]>
Date: Sat, 15 Jun 2013 04:29:24 +0000

Hi,

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