Last Call Review of draft-ietf-mipshop-mos-dns-discovery-

Request Review of draft-ietf-mipshop-mos-dns-discovery
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-06-27
Requested 2009-06-13
Authors Gabor Bajko
Draft last updated 2009-06-25
Completed reviews Secdir Last Call review of -?? by Stephen Farrell
Assignment Reviewer Stephen Farrell
State Completed
Review review-ietf-mipshop-mos-dns-discovery-secdir-lc-farrell-2009-06-25
Review completed: 2009-06-25


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

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

- 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?