Subject: [BEHAVE] AD evaluation of draft-ietf-behave-dns64-07

From: Magnus Westerlund <[email-masked]>
Date: Sat, 20 Mar 2010 08:05:38 -0700

Authors and WG,

As one of my last acts as AD I have performed an AD review of the
translator documents. As you have seen David is also reviewing the
documents in parallel as preparations for taking over the handling of
these documents. I am very pleased that the WG has managed to progress
these documents without to much delay.

See below my AD comments and questions from this review. As usual please
discuss things with me as it is as likely that I have misunderstood as
there are issues with the document. I also have to state that I have
failed to keep abreast on all the postings on the mailing list.

I do hope that these comments can be addressed quickly and if anyone
needs more discussion that we can identified that prior the IETF week is
over and take it in the BEHAVE session. However, please submit a new
draft as soon as you are able to. It is possible to submit new versions
from Monday of the IETF week.

1. Section 2
"In addition, it is required
   that IPv6 packets addressed to an IPv6 destination address that
   contains the Pref64::/n be delivered to an IPv6/IPv4 translator, so
   they can be translated into IPv4 packets."

I would propose to add  before the comma in the above sentence: " that
has this particular prefix configured"

2. Section 8.

The security consideration section is so short that it is not clear that
the security issues has been considered in all details. I would
recommend that one include some text on the potential issues that has
been considered. Even if the mitigations or protection are the same as
for regular DNS servers.

3. Section 12.2
I think the title of the RFC 5735 reference does contain a spurious
character.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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: Andrew Sullivan <[email-masked]>
Date: Sun, 21 Mar 2010 18:54:17 -0400

Hi,

Thanks for the review.

> has this particular prefix configured"

This seems reasonable to me.

> been considered. Even if the mitigations or protection are the same as

Hrm.  How does this strike you:

--%<--cut here--
 
DNS64 functions in combination with the DNS, and is therefore subject
to whatever security considerations are appropriate to the DNS mode in
which the DNS64 is operating (i.e. authoritative, recursive, or stub
resolver mode).

DNS64 has the potential to interfere with the functioning of DNSSEC,
because DNS64 by its very functioning modifies DNS answers, and DNSSEC
is designed to detect such modification and to treat modified answers
as bogus.  See the discussion above in Section 3, Section 5.5, and
Section 6.2

--%<--cut here--

?

> I think the title of the RFC 5735 reference does contain a spurious

Good catch.  Thanks!

If you and the other editors are comfortable with the proposed changes
to the Security Considerations section, then I'll update and upload.

Thanks again,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Mar 2010 08:28:53 -0700

Hi Andrew,

Regarding the security consideration section. This is an improvement. I
think this can go forward to IETF last call. It still appears to be thin
with only the DNSsec issues. But I can't find any additional issues
either so I can't propose anything else either.

Magnus

-- 

Magnus Westerlund

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Mar 2010 17:57:32 -0400

> either so I can't propose anything else either.

Remember that the DNS64 is, strictly speaking, a logical function that
just lives inside the functional perimeter of the DNS (in some mode:
stub, recursive resolver, or authority server).  I'm sensitive to what
you're saying, but I can't see that there's anything special here from
the point of view of security compared to a plain DNS component of the
same type.  (But this is an invitation for people to think of one.  If
we need something here, let's hear it.)  It could be that the secdir
will have something to say that will prompt more text.

Thanks for your help!  I'll update this presently and upload a new
version.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.