Subject: [BEHAVE] tsv-dir review of draft-ietf-behave-v4v6-bih-06

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Sep 2011 00:05:18 -0300

Hello,

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

SUMMARY
-------

This draft is on the right track but has open issues, described in the
review.

TECHNICAL
---------

* The document mentions two possible implementation alternatives, and
recommends one of them. However, lacks a discussion of the pros/cons of
each alternative, and the applicability
of each of them.

* Section 2.2, page 8:
> To avoid unnecessary fragmentation, the host's IPv4 module should be 
> configured with a small enough MTU (IPv6 link MTU - 20 bytes).

Is the "IPv6 link MTU" the MTU of the link the host is attached to, or
are you referring to the "Minimum IPv6 MTU" of 1280 bytes?

* Section 2.3, page 8:
> 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.

What are the reasons for which one would sinthesize IPv4 addresses when
real IPv4 addresses exist? -- If there are not any, then make this a
MUST (rather than a SHOULD).

* Section 2.3.2, page 9:
> The ENR may support DNSSEC.

Should you s/may/MAY/?

* Section 2.4, page 10:
> (2) When the extension name resolver gets both IPv4 and IPv6 
> addresses, but the IPv4 addresses contain only excluded IPv4 
> addresses (e.g., 127.0.0.1).  The behavior will follow case (1).

Does this mean that BIH will be employed if I do "ping6 localhost"?

* Section 2.4, pages 10-11:
> (3) When the function mapper gets a socket API function call 
> triggered by a received IPv6 packet and there is no existing mapping
>  entry for the IPv6 source address (for example, the client sent a 
> UDP request to an anycast address but a response was received from a
>  unicast address).

While I understand the scenario you're describing, it seems the
description is incorrect. In the scenario you describe, it is the *user*
(and not the packet) that triggers the socket API function call (e.g., a
"read()) -- maybe you should be saying "when the function mapper is
triggered by a received IPv6 packet..." instead?.

* Page 14, Figure 6:
> |<=======|<=========================|  An IPv4 Socket function call.

This is incorrect. You should probably say something along the lines of
"Return from the IPv4 function call" -- unless you're assuming
asynchronous I/O, which I'd bet you're not.

* Section 4.3, page 16:
> 4.3.  ICMP Message Handling
> 
> When an application needs ICMP messages values (e.g., Type, Code, 
> etc.) sent from the network layer, ICMPv4 message values MAY be 
> translated into ICMPv6 message values based on SIIT [RFC6145], and 
> vice versa.

What do you exactly mean by "needs ICMP message values"? Do you mean "if
an application needs to receive ICMP error messages.."? -- If so,
shouldn't this be a "SHOULD" rather than a "MAY"?

* Section 7.3, page 22:
> In order to allow the BIH to defend against such attacks, the BIH
> implementation MAY choose not to extend the session entry lifetime
> for a specific entry upon the reception of packets for that entry
> through the external interface.

You should probably note that this would kill session entries for
one-way communication instances.

* Section 7.4, page 22:
> BIH operates in combination with the DNS, and is therefore subject
> to whatever security considerations are appropriate to the DNS mode
> in which the BIH is operating (i.e., authoritative, recursive, or
> stub- resolver mode).

I don't follow why BIH could be operating in authoritative mode. Could
you clarify this?

* Appendix A, page 27:
> Appendix A.  API list intercepted by BIH
> 
> The following informational list includes API functions that would
> be appropriate to intercept by BIH module when implemented at socket 
> layer.

Since API function call interceptions are key for this mechanism to
work, I believe the contents of this section should be normative (unless
you're thinking of this document as a "framework". Additionally, the
list *should* be exhaustive.

* Appendix A
While the initial contents seem mostly informative, at the end of the
Appendix there are some normative requirements. IMHO, they should be
moved to the body of the document, rather than being left out in an
appendix.

EDITORIAL
---------

*Abstract:
> This draft obsoletes RFC 2767 and RFC 3338.

s/draft/document/

* Section 1, page 4:
> The supported class of applications includes those that use DNS for 
> IP address resolution and that do not embed IP address literals in 
> protocol payloads.

s/protocol payloads/application-protocol payloads/

* Section 1, page 4:
> 
>> BIH includes two major implementation options: a protocol 
>> translator between the IPv4 and the IPv6 stacks of a host, or an 
>> API translator between the IPv4 socket API module and the TCP/IP 
>> module.
> 
> s/options/alternatives/

* Section 1.1, page 5:
> which similarly provide a dual stack host means to communicate with 
> other IPv6 hosts using existing IPv4 applications.

I'd rephrase to "which similarly provides IPv4-only applications on
dual-stack hosts the means to operate over IPv6", or the like.

* Section 2, page 7:
> The proposed hosts in this document have an API or network-layer 
> translator to allow existing IPv4 applications to communicate with 
> IPv6-only peers.

s/existing/legacy/?

* Section 2, page 7:
>> For example, the Extension Name Resolver may reside in the socket 
>> API while protocol translation takes place at the networking layer
> 
> s/networking/network/

* Page 15, Figure 7:
> |   |    |       |         |   <<Reply with an IPv6 packet to.>>

Should you remove the "to."?

* Section 4.4, page 16:
> When address mapping table clean-up is required the BIH may utilize
> techniques used by network address translators, such as described in
> [RFC2663], [RFC5382], and [RFC5508].

Please insert a comma between "required" and "the BIH".

* Page 19:
> 5.  Considerations due ALG requirements

Shouldn't this be "5.  Considerations about ALG requirements" or "5.
ALG requirements considerations", instead?

* Section 7.3, page 22:
> If the number of fragments is high enough, the memory of the host
> could be exhausted.

s/high/large/ ?

* Section 7.3, page 22:
> BIN implementations MUST implement proper protection against such
> attacks, for instance, allocating a limited amount of memory for
> fragmented packet storage.

You're probably referring to one of the implementation alternatives of
BIH. But since you don't use "BIN" for referring to such implementation
alternative throughout the document, you shouldn't use it here, either.
i.e., please rephrase.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: <[email-masked]>
Date: Mon, 26 Sep 2011 14:28:34 +0000

Thank you Fernando for your review. Comments are inline:

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]] On
> Behalf Of ext Fernando Gont
> Sent: 15. syyskuuta 2011 06:05
> To: [email-masked]
> Cc: TSV Dir; [email-masked]'; [email-masked]; Behave WG
> Subject: tsv-dir review of draft-ietf-behave-v4v6-bih-06
 
> each alternative, and the applicability of each of them.

I believe the pros/cons are included here and there in the document, but I guess we could write a small section that summarizes the pros/cons of both approaches. 

> Is the "IPv6 link MTU" the MTU of the link the host is attached to, or are you
> referring to the "Minimum IPv6 MTU" of 1280 bytes?

MTU of the link the host is attached to. We can clarify.
 
> real IPv4 addresses exist? -- If there are not any, then make this a MUST
> (rather than a SHOULD).

One would synthesize IPv4 address, if the real IPv4 address was excluded (see section 2.3.1).

> > The ENR may support DNSSEC.

I think MAY is fine, SHOULD may be too strong as of currently.

> > addresses, but the IPv4 addresses contain only excluded IPv4 addresses
> > (e.g., 127.0.0.1).  The behavior will follow case (1).
> 

If the "localhost" has both IPv4 and IPv6 addresses, then the ping6 would use IPv6.. and if it has only IPv4 name, then how could the BIH map any synthesized name to IPv6 address (that is not there)? So I don’t think BIH would be employed

The bigger question maybe is that does the exclusion set include only addresses received over wire, or also addresses configured in hosts-file..  Maybe the exclusion should not exclude addresses that are locally configured.

> > (3) When the function mapper gets a socket API function call triggered
> > by a received IPv6 packet and there is no existing mapping  entry for
> > the IPv6 source address (for example, the client sent a UDP request to
> > an anycast address but a response was received from a  unicast
> > address).
> 
> While I understand the scenario you're describing, it seems the description is
> incorrect. In the scenario you describe, it is the *user* (and not the packet)
> that triggers the socket API function call (e.g., a

Agree, the proposed text is better.

> "Return from the IPv4 function call" -- unless you're assuming asynchronous
> I/O, which I'd bet you're not.

That is directly from RFC3338. If you think first arrow as “send()”-call and the quoted one as “recv()”-call, would those arrows then make sense?

> What do you exactly mean by "needs ICMP message values"? Do you mean
> "if an application needs to receive ICMP error messages.."? -- If so, shouldn't
> this be a "SHOULD" rather than a "MAY"?

Maybe that should be even MUST, as why the translator would not pass on ICMP information?

> > implementation MAY choose not to extend the session entry lifetime for
> > a specific entry upon the reception of packets for that entry through
> > the external interface.
> 
> You should probably note that this would kill session entries for one-way
> communication instances.

Like NATs usually do… but a note of this can be added.

> * Section 7.4, page 22:
> > BIH operates in combination with the DNS, and is therefore subject to
> > whatever security considerations are appropriate to the DNS mode in
> > which the BIH is operating (i.e., authoritative, recursive, or
> > stub- resolver mode).
> 
> I don't follow why BIH could be operating in authoritative mode. Could you
> clarify this?

Copy paste bug from RFC6147, will remove “authoritative”.

> > The following informational list includes API functions that would be
> > appropriate to intercept by BIH module when implemented at socket
> > layer.
> 
> Since API function call interceptions are key for this mechanism to work, I
> believe the contents of this section should be normative (unless you're
> thinking of this document as a "framework". Additionally, the list *should* be
> exhaustive.

The list is just informational and non-exhaustive, as it depends on implementation what API functions there are – and implementation may not even utilize POSIX API conventions. Hence we did not want to have this normative. That reasoning could be added of course.
 
> moved to the body of the document, rather than being left out in an

The appendix is informative, so the keywords will be removed.

> EDITORIAL

These were ok, will be handled.

> You're probably referring to one of the implementation alternatives of BIH.
> But since you don't use "BIN" for referring to such implementation

Typo, that should be BIH, but maybe better could be “network layer implementation of option of BIH” as there probably are no fragments on socket level implementation..

Best regards,

	Teemu