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

[<[e-mail]>]

Thank you very much for review. 

Comments inline:

> -----Original Message-----
> From: ext Xiaodong Lee [mailto:[e-mail]]
> Sent: 22. syyskuuta 2011 03:33
> To: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Savolainen Teemu (Nokia-CTO/Tampere);
> [e-mail]; [e-mail]
> Subject: apps-team review of draft-ietf-behave-v4v6-bih-06
 
> 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".

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