Subject: [apps-discuss] apps-team review of draft-ietf-behave-v4v6-bih-06

From: Xiaodong Lee <[email-masked]>
Date: Thu, 22 Sep 2011 08:32:37 +0800

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-behave-v4v6-bih-06

Title: Dual Stack Hosts Using "Bump-in-the-Host" (BIH)

Reviewer: Xiaodong Lee

Review Date: 2011-09-21

Review Summary:
This draft is almost ready for publication but has a few issues that
should be clarified and fixed before publication.

Major Issues:
“BIH has the potential to interfere with the functioning of DNSSEC,
because BIH modifies DNS answers, and DNSSEC is designed to detect such
modifications and to treat modified answers as bogus.”  as in Section 7.4.

This document overall provides an valuable 4-6 translation solution.
However, the effects this draft will pose on DNS should be deliberately
considered. As described in BIH, ENR (Extension Name Resolve) is to
modify DNS request and response messages as in ” The Extension Name
Resolver (ENR) returns an answer in response to the IPv4 application’s
name resolution request.” , which means BIH has the potential to
interfere with the functioning of DNSSEC.

Yet circumstances alter cases due to the two different ENR
implementation options. In the case of the socket API layer
implementation option, there is no conflicts with DNSSEC. However, in
the case of the network layer implementation option, BIH modifies DNS
answers, and DNSSEC is designed to detect such modifications and to
treat modified answers as bogus. This draft recognizes the issue and
prefers the former as in “Hence the socket API layer option is
RECOMMENDED.” in section 2.3. Since this draft is intended for standard
track, RECOMMENDED is not strong enough, the socket API layer option
should be the “SHOULD” solution or specify that “One implementation
SHOULD NOT interferes DNSSEC mechanism”.

Minor Issues: NA

Nits: NA

-- 
--
Xiaodong LEE
VP&CTO, CNNIC
Professor, Chinese Academy of Sciences

---

From: <[email-masked]>
Date: Mon, 26 Sep 2011 15:05:52 +0000

Thank you very much for review. 

Comments inline:

> -----Original Message-----
> From: ext Xiaodong Lee [mailto:[email-masked]]
> Sent: 22. syyskuuta 2011 03:33
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Savolainen Teemu (Nokia-CTO/Tampere);
> [email-masked]; [email-masked]
> Subject: apps-team review of draft-ietf-behave-v4v6-bih-06
 
> Major Issues:
> "BIH has the potential to interfere with the functioning of DNSSEC,
> modifications and to treat modified answers as bogus."  as in Section 7.4.
> 
> modify DNS request and response messages as in " The Extension Name
> Resolver (ENR) returns an answer in response to the IPv4 application's
> name resolution request." , which means BIH has the potential to
> prefers the former as in "Hence the socket API layer option is
> RECOMMENDED." in section 2.3. Since this draft is intended for standard
> should be the "SHOULD" solution or specify that "One implementation
> SHOULD NOT interferes DNSSEC mechanism".

Current wording uses RECOMMENDED, as DNSSEC can be made to work on either
case. It is easier and simpler in the socket API level implementation case
(that's why RECOMMENDED), but even in the network layer implementation it
should be possible to configure the stub resolver to trust on ENR, which can
then perform the validation. The network layer implementation of course
cannot be simply dropped into any host, as DNSSEC-aware resolver on the host
must work properly with ENR (especially if DNSSEC-aware resolver needs to
trust ENR).

So..  if the current wording needs improvement, maybe SHOULD be fine e.g.
due simplicity and having less things that can go wrong, or we could leave
the recommendation totally out. In the tsv-area review there was request to
have pros/cons better explained. If a new pros/cons section would be
created, it could then be clear that DNSSEC support is easier to arrange in
socket API level implementation option.

Best regards,

	Teemu