[secdir] Secdir review of draft-ietf-mipshop-mos-dns-discovery-06

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 23 June 2009 17:52 UTC

Message-ID: <4A411679.4020009@cs.tcd.ie>
Date: Tue, 23 Jun 2009 18:52:57 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird 2.0.0.21 (X11/20090302)
MIME-Version: 1.0
To: sec-ads@ietf.org, secdir@ietf.org, draft-ietf-mipshop-mos-dns-discovery@tools.ietf.org, mipshop-chairs@tools.ietf.org, IESG <iesg@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [secdir] Secdir review of draft-ietf-mipshop-mos-dns-discovery-06
Precedence: list

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.

The document defines a way to find IEEE 802.21 servers using NAPTR
resource records.

Since I'm not familiar with IEEE 802.21 I've no idea how security
sensitive one ought be about getting told which server to use.
Perhaps there's a general 802.21 security considerations reference
that should be pointed to from the security considerations here?
I guess the concern would be if this way of finding servers
introduced some new way to e.g. eavesdrop on calls/sessions but
since I don't know 802.21 I can't tell if that's the case or not
(as it happens I suspect there'd be easier ways to cheat if
that were the case).

Other than that, the security considerations seem fine.

This is of course yet another spec that needs DNSSEC to get data
origin authentication. Hopefully that'll be possible soon.

A couple of non-security things that I noticed:

- There's a MUST about what the MN does when in its home domain
  but I'm not sure how a MN would know that. Perhaps that's
  covered in some other mipshop document?

- I didn't see where allowed values for the NAPTR flags field
  were defined but the examples show "s" - are other values
  allowed? Does "s" mean the replacement indicates an SRV
  lookup?

- Are the order and pref values in the example NAPTR records
  correct?

- The document discourages the use of the regexp field but
  if there's no need for it, why not say that the regexp
  MUST be empty?

Stephen.

[secdir] Secdir review of draft-ietf-mipshop-mos-… Stephen Farrell