Re: [tcpm] Comments on Soft Errors I-D: draft-ietf-tcpm-tcp-soft-errors-06

[Gorry Fairhurst <[e-mail]>]

OK.

I am not suggesting the document creates new rules or methods.
My suggestion is that the  author could consider if this should
or should not be documented (in the security considerations, for 
example). This is not a showstopper to me.

Gorry

On Tue, 3 Jul 2007, Joe Touch wrote:
>
> Gorry Fairhurst wrote:
>> My observation was only that if a host repeatedly opens several TCP sessions
>> to search for a valid IP address (e.g. Attempting to try all IP addresses
>> that correspond to abc.com), then it *could* consume much more network &
>> host resources, than a host that opens a session to each address in turn,
>> with a backoff between each request.
>
> That's true, but there aren't rules for either parallel or serial. I.e.,
> a host that opens 2 each (v4, v6) in parallel (then sequences through v4
> and v6) consumes less resources than one that opens 8 in serial. It's a
> matter of rules governing how to try the sequence.
>
> I.e., either one could swamp things, depending on how the application works.
>
> Joe
>
>>
>> Gorry
>>
>>
>> On 2/7/07 22:13, "Joe Touch" <[e-mail]> wrote:
>>
>>>
>>> Gorry Fairhurst wrote:
>>>> The document looks in good shape, and seemed easy to read to me.
>>>>
>>>> Here are a few comments on the latest draft, really relating to
>>>> congestion-control and increased state.
>>>>
>>>> Best wishes,
>>>>
>>>> Gorry
>>>>
>>>> In Section 3.2 (Problems that may arise with Dual Stack IPv6 on by Default):
>>>> There may also be drawbacks in this approach --- e.g. this creates
>>>> additional host state, and could also establish additional context state for
>>>> other devices along the network path (NAT. Firewall, link compressors,
>>>> encryption devices, etc).
>>>>
>>>> Similarly, section 5 does not speak of the effects of a non-standard
>>>> approach on the network. One question I have relates to the behaviour of a
>>>> parallel and/or successive strategy to exploit multiple IP bindings. If I
>>>> understand, this opens a (potentially) large number of connections, to see
>>>> which succeeds. This seems to me to be injecting extra SYN packets into the
>>>> network, and therefore can potentially waste network resources.
>>>>
>>>> If these connections are in series, each is opened one after another, after
>>>> a "fixed" time (i.e. not exponentially backed-off)... which generates more
>>>> state or more packets/rtt than using the standard algorithm.
>>>>
>>>> When connections are opened in parallel, this is even more noted.  In an
>>>> extreme case, this could look like a syn-attack or lead to congestion-based
>>>> loss.  Are these concerns valid? Is this only used for a single IPv4 and an
>>>> equivalent IPv6 address? Are there limitations that would mitigate these
>>>> effects if I had many candidate addresses?
>>> RFC1122 discusses the technique of trying multiple addresses, and it is
>>> issue only when a DNS name resolves to multiple addresses. It would be
>>> unusual for a large number of addresses to refer to the same host; in
>>> many cases, there are only a small number for one host (typically for
>>> IPv4 and IPv6), and the larger number is used for DNS rotation to
>>> distribute load to a number of servers. There are exceptions, such as
>>> where multiple IP addresses are used for shared web service -- though
>>> that has fallen out of use as newer HTTP protocols determine the host in
>>> the request (sending GET and the DNS name, in addition to the filename)
>>> rather than only by the IP address (which was the only way compatible
>>> with HTTP 1.0, e.g.).
>>>
>>> Whether in serial or in parallel, methods to moderate the number of
>>> outstanding SYNs are probably useful. But this isn't the focus of this
>>> document anyway.
>>>
>>> Joe
>>>
>>>> ----
>>>>
>>>> The remaining comments are editorial, for the author to consider in their
>>>> next rev:
>>>>
>>>> INTRODUCTION, paragraph 14:
>>>> - Could consider to tighten English a little.
>>>>
>>>> CURRENT:
>>>>     This document describes a non-standard, but widely implemented,
>>>>     modification to TCP's handling of ICMP soft error messages, that
>>>>     rejects pending connection-requests when those error messages are
>>>>     received.  This behavior reduces the likelihood of long delays
>>>>     between connection establishment attempts that may arise in a number
>>>>     of scenarios, including one in which dual stack nodes that have IPv6
>>>>     enabled by default are deployed in IPv4 or mixed IPv4 and IPv6
>>>>     environments.
>>>> SUGGESTION:
>>>>     This document describes a non-standard, but widely implemented,
>>>>     modification to TCP's handling of ICMP soft error messages, which
>>>>     rejects pending connection-requests when these error messages are
>>>>     received.  This behavior reduces the likelihood of long delays
>>>>     between connection establishment attempts that may arise in a number
>>>>     of scenarios, including one in which dual stack nodes that have IPv6
>>>>     enabled by default are deployed in IPv4, or mixed IPv4 and IPv6
>>>>     environments.
>>>>
>>>> Section 1., paragraph 2:
>>>>     In the Internet architecture, the Internet Control Message Protocol
>>>>     (ICMP) [RFC0792] is one fault isolation technique to report network
>>>>     error conditions to the hosts sending datagrams over the network.
>>>>
>>>> - Add the IPv6 ICMP reference too here?
>>>>
>>>>
>>>> Section 3.2., paragraph 1:
>>>> - Language could perhaps be improved.
>>>> CURRENT:
>>>>     A particular scenario in which the above sketched type of problem may
>>>>     occur regularly is that where dual stack nodes that have IPv6 enabled
>>>>     by default are deployed in IPv4 or mixed IPv4 and IPv6 environments,
>>>>     and the IPv6 connectivity is non-existent
>>>>     [I-D.ietf-v6ops-v6onbydefault].
>>>>
>>>> SUGGESTION:
>>>>
>>>>     A particular scenario in which the problems outlined above
>>>>     can occur regularly arises where dual stack nodes (with IPv6 enabled
>>>>     by default) are deployed in IPv4 or mixed IPv4 and IPv6 environments,
>>>>     and the IPv6 connectivity is non-existent.
>>>>     [I-D.ietf-v6ops-v6onbydefault].
>>>>
>>>> Section 4.1., paragraph 0:
>>>> Could Add: Section 5 discusses drawbacks to changing this behaviour.
>>>>
>>>>
>>>> Section 4.2., paragraph 1:
>>>> - Language could perhaps be improved.
>>>> OLD:
>>>>     A more conservative approach than simply treating soft errors as hard
>>>>     errors as described above would be to abort a connection in the SYN-
>>>>     SENT or SYN-RECEIVED states only after an ICMP Destination
>>>>     Unreachable has been received a specified number of times, and the
>>>>     SYN segment has been retransmitted more than some specified number of
>>>>     times.
>>>>
>>>> SUGGESTION:
>>>>     An approach that is more conservative than simply treating soft errors
>>>>     as hard
>>>>     errors, as described above, would be to abort a connection in the SYN-
>>>>     SENT or SYN-RECEIVED states only after an ICMP Destination
>>>>     Unreachable has been received a specified number of times, and the
>>>>     SYN segment has been retransmitted more than some specified number of
>>>>     times.
>>>>
>>>> Section 5, paragraph 1:
>>>> - Capital E?
>>>> CURRENT:
>>>>     +----------------------------------+--------------------------------+
>>>>     |   Time Exceeded (codes 0 and 1)  |  Time exceeded (codes 0 and 1) |
>>>>                                                ^
>>>>
>>>> Section 5.3., paragraph 1:
>>>> CURRENT:
>>>>     Some NATs respond to an unsolicited inbound SYN segment with an ICMP
>>>>     soft error message.  If the system sending the unsolicited SYN
>>>>     segment implements the workaround described in this document, it will
>>>>     abort the connection upon receipt of the ICMP error message, thus
>>>>     probably preventing TCP's simultaneous open through the NAT from
>>>>     succeeding.  However, it must be stressed that those NATs described
>>>>     in this section are not BEHAVE-compliant, and therefore should
>>>>     implement REQ-4 of [I-D.ietf-behave-tcp] instead.
>>>>
>>>> SUGGESTION:
>>>>     Some NATs respond to an unsolicited inbound SYN segment with an ICMP
>>>>     soft error message.  If the system sending the unsolicited SYN
>>>>     segment implements the workaround described in this document, it will
>>>>     abort the connection upon receipt of the ICMP error message, thus
>>>>     probably preventing TCP's simultaneous open through the NAT from
>>>>     succeeding.  However, it must be stressed that the NATs described
>>>>     in this section are not BEHAVE-compliant, and therefore should
>>>>     implement REQ-4 of [I-D.ietf-behave-tcp] instead.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [e-mail]
>>>> https://www1.ietf.org/mailman/listinfo/tcpm
>>
>
> -- 
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
>
>

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm