Subject: [BEHAVE] AD review of draft-ietf-behave-v4v6-bih-05

From: "David Harrington" <[email-masked]>
Date: Wed, 3 Aug 2011 18:50:57 -0400

Hi,

Below is the AD review of draft-ietf-behave-v4v6-bih-05.
Most are editorial comments.
Some are RFC2119-related.
Some are simply questions I would like answered, and the answer might
be best in the document so other readers know the answers as well.

===

AD review of draft-ietf-behave-v4v6-bih-05 

The abstract or section 1.1 should explain WHY a successor is needed.

2.1 refers to Appendix B; there is no appendix B.

Typically appendices are used for non-normative content, but this
appendix lists functions that MUST be intercepted (according to 2.1).
This would probably be better placed in the main part of the document.

2.1 says the APIs MUST be intercepted; the Appendix says they SHOULD
be intercepted. Which is it?

2.2 says "Protocol translation SHOULD NOT be performed for IPv4
packets sent to the IPv4 address range used by local synthesis and for
which a mapping table entry does not exist. The implementation SHOULD
attempt to route such packets via IPv4 interfaces instead." Why should
and not MUST? Is should, what ar ethe valid exceptions to the
recommended practice?

2.3 "returns a proper answer" => returns an answer

2.3 RECOMMENDS the socket API layer option. When is it appropriate to
use the other option?

in 2.3 "In either implementation option, if there is a real IPv4
address available, the ENR SHOULD NOT synthesize IPv4 addresses. By
default an ENR implementation MUST NOT synthesize IPv4 addresses when
real IPv4 addresses exist." Why only should not? What is the valid
exception to a MUST NOT? (is this discussed elsewhere in the
document?)

2.3.1 what is a martian address? can you give a reference for this
phrase?

overuse of "essentially"; this is typically not needed where it is
used. "essentially the same" => similar

in 2.3.2 "The ENR can support DNSSEC as any resolver on a host." I
don't understand this sentence, especially "as any resolver".

in 2.3.2, the main resolver MUST use the CD bit; what are the
operational implications of requiring this?

in 2.3.2, are DNS questions the same as DNS queries?

in 2.3.2, I don't like the wording in "In order to properly support
DNSSEC, the ENR SHOULD be implemented at the socket API level. If the
socket API level implementation is not possible, DNSSEC support SHOULD
be provided by other means." Properly support is not a technical
phrase;  do you mean to be compliant to dnssec? Do you mean to secure
the DNS environment?  
If the socket API is not implemented, why isn't DNSSEC support MUST be
provided by other means? If an implementation does not provide dnssec
support by other means, then what happens to the security properties
of the trusted environment? would not doing this create a
vulnerability?

in 4.4, why is the primary address space /30, whereas the other
address spaces are /20s?

in 7, "The security considerations of BIH mostly relies on that of
[RFC6146]." Do you mean "The security considerations found in RFC6146
apply, with the following additional considerations specific to BIH"? 

in 7, it says "the differences are due to ..." - the differences
between what and what? Do you mean between 6146 and this document? If
so, simply discuss the considerations for this document. Doing this as
a comparison to the other document is a bit confusing, and would
really require the reader to have both documents open and to do a diff
to understand your text.

s/In the socket-layer implementation approach, the differences are due
to the address translation occurring at the API and not in the network
layer. That is, since the mechanism/When the implementation/

in 7, "So BIH should employ the same sort of protection techniques as
NAT64 [RFC6146] does." I am not sure which protections you refer to
here. I think it would be better to point to specific relevant
solutions in 6146. The only mention of denial of service in 6146 is in
section 1.2.3. Is that the protection you mean?

in 9, s/The author thanks/The authors thank/ 

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: <[email-masked]>
Date: Wed, 10 Aug 2011 07:40:37 +0000

Hi David,

Thank you very much for your review. The draft-ietf-behave-v4v6-bih-06 attempts to answer all the issues you raised. Below inline are few additional comments.

The diff to -05 is available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v4v6-bih-06

Thank you,

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext David Harrington
> Sent: 04. elokuuta 2011 01:51
> To: [email-masked]; [email-masked]; behave-
> [email-masked]
> Subject: [BEHAVE] AD review of draft-ietf-behave-v4v6-bih-05
 
> 2.3 RECOMMENDS the socket API layer option. When is it appropriate to use
> the other option?

When software implementing API layer cannot be changed, for example, when it is only possibly to add virtual interface drivers (of sorts) and not to touch API implementation. For example, an operating system might be completely closed source providing only possibilities to create plug-ins at network layer, hence making it possible to only have the network layer implementation.

> in 2.3.2, I don't like the wording in "In order to properly support DNSSEC, the
> ENR SHOULD be implemented at the socket API level. If the socket API level
> implementation is not possible, DNSSEC support SHOULD be provided by other
> means." Properly support is not a technical phrase;  do you mean to be
> compliant to dnssec? Do you mean to secure the DNS environment?
> support by other means, then what happens to the security properties of the
> trusted environment? would not doing this create a vulnerability?

The -06 now recommends API implementation option as with that DNSSEC support comes naturally. If ENR is implemented at the network layer, well it may support DNSSEC, but I hesitate to use MUST when it comes to DNSSEC support on hosts (I still don't recall IETF document that would set DNSSEC as MUST for host).

> in 7, "The security considerations of BIH mostly relies on that of [RFC6146]." Do
> you mean "The security considerations found in RFC6146 apply, with the
> following additional considerations specific to BIH"?
> in 7, it says "the differences are due to ..." - the differences between what and
> what? Do you mean between 6146 and this document? If so, simply discuss the
> considerations for this document. Doing this as a comparison to the other
> document is a bit confusing, and would really require the reader to have both
> documents open and to do a diff to understand your text.

The section 7 security considerations is now fully rewritten by fetching quite some content from RFC6146 and RFC6147 security considerations and modifying those to suit BIH.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 10 Aug 2011 10:51:25 -0400

Hi,

comments inline. 

> When software implementing API layer cannot be changed, for 
> example, when it is only possibly to add virtual interface 
> drivers (of sorts) and not to touch API implementation. For 
> example, an operating system might be completely closed 
> source providing only possibilities to create plug-ins at 
> network layer, hence making it possible to only have the 
> network layer implementation.

You missed the point. You need to discuss IN THE DOCUMENT when it is
acceptable to not follow the recommendation.

> The -06 now recommends API implementation option as with that 
> DNSSEC support comes naturally. If ENR is implemented at the 
> network layer, well it may support DNSSEC, but I hesitate to 
> use MUST when it comes to DNSSEC support on hosts (I still 
> don't recall IETF document that would set DNSSEC as MUST for host).

see below

> The section 7 security considerations is now fully rewritten 
> by fetching quite some content from RFC6146 and RFC6147 
> security considerations and modifying those to suit BIH.
> 
> 
FYI.
I think the changes include a lot of changes to normative text.
Therefore the draft probably requires WG review.
I am working with Dan and Dave, who should handle that process.

David Harrington