RE: Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt

[[e-mail]]

Fernando,

> >(1) The I-D Tracker says that the v6ops-v6onbydefault draft is Dead.
> >Relevant portions of that draft should be reproduced or otherwise
> >explained in Section 3.2.
> 
> The reference to this I-D has been updated to the corresponding RFC.

Thanks - please send the reference to the secretariat, because the
I-D Tracker doesn't record the fact that this draft was published as
an RFC.

> >As part of doing this, please state
> >whether trying v6 and v4 connections in parallel is a good idea or
> >not and why.
> 
> The document does not discuss alternative approaches, at it just 
> documents this alternative reaction to soft errors, as implemented in 
> a number of stacks.
> 
> (FYI, the draft originally aimed at Std. Track, and discussed other 
> alternative  approaches for dealing with the problem of long delays 
> between connection establishment attempts. Then we changed the draft 
> category to "Informational", to simply document this behavior. At 
> that point, the discussion of parallel connections and other 
> approaches was dropped).

I don't think just ignoring this problem is acceptable, but a reference
to a discussion of what can be done about it in that RFC or some other
document should suffice.

> >(2) Section 4.1 describes a mechanism from RFC 3168 that retransmits
a
> >modified SYN when an RST is received in response to an ECN-setup SYN,
> >and suggests that this mechanism is applicable to ICMP errors
received
> >in response to an ECN-setup SYN.  This mechanism was specified in
> >RFC 3168 because there were known deployed middleboxes with this
> >problem-causing RST behavior, and the mechanism was necessary to deal
> >with them.  Are there any known middleboxes that send an ICMP error
> >in response to a SYN that signals ECN capability?
> >- If yes, state the specific ICMP error(s) that is(are) used and
limit
> >         the recommendation to the actual error(s).
> >- If no, remove this entire RFC 3168 discussion as speculative, or
> >         describe it as a possible response should this problem
scenario
> >         ever arise in practice.
> 
> I am particularly referring to firewalls, that can be configured to 
> reject incoming connections with either RST segment, ICMP error 
> messages, or silently.
> 
> Would your comment be addressed if I incorporate a small paragraph to 
> clarify this? The resulting text would read:
> --- cut here ----
>     [RFC3168] states that a host that receives a RST in response to
the
>     transmission of an ECN-setup SYN packet MAY resend a SYN with CWR
and
>     ECE cleared.  This is meant to deal with faulty middle-boxes that
>     reject connections when a SYN segment has the ECE and CWR bits
set.
>     Given that this section describes a modification that processes
ICMP
>     error messages as hard errors when they are received for a
connection
>     in any of the non-synchronized states, systems implementing this
>     behavior could resend the SYN segment with the ECE and CWR bits
>     cleared when an ICMP error message is received in response to a
SYN
>     segment that had these bits set.
> 
> This would address those scenarios in which a middle-box such as a 
> firewall rejects incoming connection requests with an ICMP soft error 
> simply because the ECE and CWR bits were set in the incoming 
> SYN segment.
> ---- cut here ----
> 
> (Only the last paragraph was added).

I see two problems:
- I want to see the offending ICMP soft errors named as opposed
	to a general allowance being made for all soft errors.
- I believe the concept in that last paragraph belongs before the
	"Given that ..." sentence.

Try the following two paragraphs:

     [RFC3168] states that a host that receives a RST in response to the
     transmission of an ECN-setup SYN packet MAY resend a SYN with CWR
and
     ECE cleared.  This is meant to deal with faulty middle-boxes that
     reject connections when a SYN segment has the ECE and CWR bits set.

    Some faulty middle-boxes (e.g., firewalls) may reject connections
    with an ICMP soft error of <XXX> instead of an RST.  Therefore a
    system that processes ICMP error messages as hard errors when they
    are received for a connection in any of the non-synchronized states,
    MAY respond to an <XXX> ICMP error message received in response to a
    SYN segment with the ECE and CWR bits set by retransmitting that SYN
    segment with those bits cleared instead of abandoning the
connection.

The actual ICMP error or errors need to be filled in to replace <XXX>
above.

> >(3) Section 5.3 describes a NAT behavior that causes a host TCP
problem
> >and then suggests changing the NAT to fix it.  While that's a good
idea
> >in an ideal world (and needs to be stated in the draft), in practice,
> >deployed NATs have to be dealt with as-is.  In addition to
recommending
> >fixing the NAT, please discuss what could be done when the NAT cannot
> >be fixed.
> 
> There's not much that could be done. However, this would just break 
> TCP simultaneous opens, that are unlikely. (As a matter of fact, 
> there are even end-system implementations of TCP that do not support 
> simultaneous opens)

Please add text stating that (only thing broken is TCP simultaneous
opens,
which is tolerable in many situations)..
 
> >Nits:
> >
> >Section 1 - reduce generality of this text.
> >OLD:
> >    This document analyzes the fault recovery strategy of TCP
[RFC0793],
> >    and the problems that may arise due to TCP's reaction to ICMP
soft
> >    errors.
> >NEW:
> >    This document analyzes problems that may arise due to TCP
[RFC0793]
> >    fault recovery reactions to ICMP soft errors.
> 
> I have not incorporated this change. But please let me know if you 
> feel strongly about it.

I think the old wording seriously overstates the scope of the draft, but
this is an editorial problem, not a technical one.  I would still prefer
to see this changed.

> >It would be good to provide the text expansion of the codes in
> >Figure 1, as was done in the text before the figure.
> 
> I guess this would mess up the table, which is suppose to provide a 
> quick reference for extrapolating the ICMPv4 soft errors to their 
> ICMPv6 counter-parts. Therefore I have not incorporated this 
> suggested change. However, please let me know if you feel 
> strongly about it.

Ok.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf