Subject: [tcpm] WG Last Call for ICMP Attacks

From: David Borman <[email-masked]>
Date: Tue, 1 Sep 2009 10:12:04 -0500

Wes and I are starting a Working Group Last Call for the ICMP Attacks  
document:

	http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-06.txt

This document is intended to be published as Informational.  The WGLC  
will end on Sep. 15, 2009.  Please send any comments to list before  
then.

		-David Borman & Wes Eddy, TCPM WG chairs

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 2 Sep 2009 14:48:34 -0600

1.
ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,
   and is used mainly for reporting network error conditions.

ICMP is part of the IP protocol suite.

2.2
Therefore, in the case of TCP, an attacker could send a forged ICMP
   message to the attacked system, and, as long as he is able to guess
   the four-tuple (i.e., Source IP Address, Source TCP port, Destination
   IP Address, and Destination TCP port) that identifies the
   communication instance to be attacked, he will be able to use ICMP to
   perform a variety of attacks.

Forged usually implies that source ip address has been spoofed usually to come from some type of trusted host.
Crafted is the term generally used to mean the packets contents (not header) were modified.
In this case there is no need to spoof the source ip address as the end host has no knowledge about the routers in between them and the end host system. So I recommend you change forged to crafted.

2.2
The need to be more more cautious when processing received ICMP error
   messages in order to mitigate or eliminate the impact of the attacks

Grammer:
The need to be more cautious when processing received ICMP error
   messages in order to mitigate or eliminate the impact of the attacks

4.1
Many TCP implementations have incorporated a validation check so
   makes TCP react only to those ICMP error messages elicited by
   segments that were "in-flight" to the destination system.

Grammer and minor correction for elicited:
Many TCP implementations have incorporated a validation check to
make TCP react only to those ICMP error messages that 
appear to have been caused by segments that were "in-flight" to the destination system.

 5.2
Assuming that once a connection is
      established it is not usual for the transport protocol to change
      (or be reloaded), it should be unusual to get these error
      messages.
Should be:
Assuming that once a connection is
      established it is usual for the transport protocol to change
      (or be reloaded), it should be unusual to get these error
      messages.

...(still 5.2)

ICMPv6 type 1 (Destination Unreachable), code 1 (communication with
   destination administratively prohibited)

      This error message indicates that the destination is unreachable
      because of an administrative policy.  For connection-oriented
      protocols such as TCP, one could expect to receive such an error
      as the result of a connection-establishment attempt.  Receiving
      such an error for a connection in any of the synchronized states
      would mean that the administrative policy changed during the life
      of the connection.  However, in the same way this error condition
      (which was not present when the conenction was established)
      appeared, it could get solved solved in the near term.

This actually does occur in some cases where bruteforce password attempts causes a tool such as fail2ban to block access.
and connection not conenction.

7.1
The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in the
   IP header to dynamically discover the Path MTU.  The basic idea
   behind the PMTUD mechanism is that a source system assumes that the
   MTU of the path is that of the first hop, and sends all its datagrams
   with the DF bit set.  If any of the datagrams is too large to be
   forwarded without fragmentation by some intermediate router, the
   router will discard the corresponding datagram, and will return an
   ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF
   set" (code 4) error message to the sending system.  This message will
   report the MTU of the constricting hop, so that the sending system
   can reduce the assumed Path-MTU accordingly.

Spelling and grammer:
If any of the datagrams is too large ->
If any of the datagrams are too large.

fragementation needed

...

As discussed in both [RFC1191] and [RFC1981], the Path-MTU Discovery
   mechanism can be used to attack TCP.  An attacker could send a forged
   ICMP "Destination Unreachable, fragmentation needed and DF set"
   packet (or their ICMPv6 counterpart) to the sending system,
   advertising a small Next-Hop MTU.  As a result, the attacked system
   would reduce the size of the packets it sends for the corresponding
   connection accordingly.

Again I would suggest crafted instead of forged.

7.2
The IETF has standardized a Path-MTU Discuvery mechanism called
   "Packetization Layer Path MTU Discovery" that does not depend on ICMP
   error messages.

Spelling -> Discovery

Review stopped at page 17.

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David Borman
> Sent: Tuesday, September 01, 2009 9:12 AM
> To: tcpm Extensions WG
> Subject: [tcpm] WG Last Call for ICMP Attacks
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Sep 2009 14:08:45 -0700

> In this case there is no need to spoof the source ip address as the end host has no knowledge about the routers in between them and the end host system. So I recommend you change forged to crafted.

I've not heard that there was such clarity on the term forged or
crafted, but neither is the case here.

The attacker emits an ICMP message. It doesn't need a falsified header.
It doesn't need to be a "modified" packet. E.g., it can be created based
on information seen on the media.

It might just be called a "false ICMP message", i.e., it's reporting an
event that didn't happen.

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 2 Sep 2009 16:06:55 -0600

The distinction is from SANS classes but also commonly used in network forensics.

Crafted implies it wasn't created naturally by an OS.
A "special" tool is required to "craft" the packets.
A crafted packet MIGHT have also had its source IP forged.
So I see "forged or spoofed" as a subset of crafted packets.

"ICMP packet with falsified content" would be a good description.

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Wednesday, September 02, 2009 3:09 PM
> To: Smith, Donald
> Cc: 'David Borman'; 'tcpm Extensions WG'
> Subject: Re: [tcpm] WG Last Call for ICMP Attacks
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Smith, Donald wrote:
> > 1.
> > Forged usually implies that source ip address has been 
> spoofed usually to come from some type of trusted host.
> > In this case there is no need to spoof the source ip 
> address as the end host has no knowledge about the routers in 
> between them and the end host system. So I recommend you 
> change forged to crafted.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkqe3t0ACgkQE5f5cImnZrvj4QCeLodfjABk7/bGxLSU9wv4dV+N
> 0foAoJ5qPOCkzsS/w0kvpuOzJdChMcCb
> =BJU2
> -----END PGP SIGNATURE-----
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 Sep 2009 16:05:09 -0700

Smith, Donald wrote:
...
> "ICMP packet with falsified content" would be a good description.

Sounds better to me.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 03 Sep 2009 01:48:49 -0300

Hello, Donald,

Thanks so much for your feedback! Comments inline.... (I have removed
those comments that I will apply and didn't need further clarification...)

Smith, Donald wrote:
> 1. ICMP [RFC0792] is a fundamental part of the TCP/IP protocol suite,

The protocol suite is referred to as "TCP/IP"...

> 2.2 Therefore, in the case of TCP, an attacker could send a forged
> ICMP message to the attacked system, and, as long as he is able to
> guess the four-tuple (i.e., Source IP Address, Source TCP port,
> Destination IP Address, and Destination TCP port) that identifies the
>  communication instance to be attacked, he will be able to use ICMP
> to perform a variety of attacks.
> 
> Forged usually implies that source ip address has been spoofed
> usually to come from some type of trusted host. Crafted is the term
[...]

I'll adopt the term/phrase you and Joe have converged to.

> 4.1 Many TCP implementations have incorporated a validation check so 
> Grammer and minor correction for elicited: Many TCP implementations
> have incorporated a validation check to make TCP react only to those
> ICMP error messages that appear to have been caused by segments that
> were "in-flight" to the destination system.

Does "elicited" sound bad? (english as a second language here, sorry)

> 5.2 Assuming that once a connection is established it is not usual
> for the transport protocol to change (or be reloaded), it should be
> unusual to get these error messages. Should be: Assuming that once a
> connection is established it is usual for the transport protocol to
> change (or be reloaded), it should be unusual to get these error 
> messages.
> 
> 
> ...(still 5.2)
> 
> protocols such as TCP, one could expect to receive such an error as
> the result of a connection-establishment attempt.  Receiving such an
> error for a connection in any of the synchronized states would mean
> that the administrative policy changed during the life of the
> connection.  However, in the same way this error condition (which was
> not present when the conenction was established) appeared, it could
> get solved solved in the near term.
> 
> This actually does occur in some cases where bruteforce password
> attempts causes a tool such as fail2ban to block access. and
> connection not conenction.

Ok. Will add a note on this. If you have any proposed text, please let
me know.

> 7.1 The PMTUD mechanism for IPv4 uses the Don't Fragment (DF) bit in
> the IP header to dynamically discover the Path MTU.  The basic idea 
> Spelling and grammer: If any of the datagrams is too large -> If any
> of the datagrams are too large.

mmmm... aren't we meaning that "as long as *one* of them is too large"?

> Again I would suggest crafted instead of forged.

Well, even with the discussion you provided about "forged" vs.
"crafted", the attacker does forge the IP/TCP packet contained in the
ICMP payload...

Thanks so much!

Kind 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: Thu, 3 Sep 2009 11:05:47 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Fernando Gont
> Sent: 03 September 2009 05:49
> To: Smith, Donald
> Cc: 'tcpm Extensions WG'; 'David Borman'

"elicited" implies that the packet specifically sought the ICMP packet
to be sent (which I guess would indeed be the case in tcptraceroute)
whereas the alternate wording is trying to make it clear that the ICMP
packet wasn't the desired response in the first place. Not sure how
clear my explanation actually is! 

Possible alternative wording: "Many TCP implementations have
incorporated a validation check such that they only react to those ICMP
messages that appear to relate to segments currently "in-flight" to the
destination system."

---

From: Fernando Gont <[email-masked]>
Date: Thu, 03 Sep 2009 13:59:56 -0300

> clear my explanation actually is! 

Clear as water. :-) Thanks!

> messages that appear to relate to segments currently "in-flight" to the

Will incorporate this one. Thanks!

Kind regards,

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 3 Sep 2009 11:58:31 -0600

Hi Fernando. Thanks for reviewing my comments.
Toby and others did a good job of answering most of the addition questions but I have one or two clarifications below inline.

01100101000010|10011010111101?
Hint 7 bit ascii
[email-masked] gcia  

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, September 03, 2009 4:06 AM
> To: [email-masked]; Smith, Donald
> Cc: [email-masked]; [email-masked]
> Subject: RE: [tcpm] WG Last Call for ICMP Attacks
> 
> 
> 
Since this documents focus is TCP/IP's interaction with ICMP I am ok with it
but ICMP is an IP protocol (protocol number 1 :) A LOT of people
use the expression "tcp/ip" to describe things that are IP (not dependant on tcp).

> > Does "elicited" sound bad? (english as a second language 
Not bad there is an implication that I don't think you intended.

> messages that appear to relate to segments currently 
This wording is better. Yes elicited tends to imply "caused by".
By adding the "appear" above this statement is clearer.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 03 Sep 2009 15:28:02 -0300

Hello, Donnald,

Comments inline....

> Not bad there is an implication that I don't think you intended.

That pointed out by Toby?

Thanks again!

Kind regards,

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 3 Sep 2009 13:33:20 -0600

> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Thursday, September 03, 2009 12:28 PM
> To: Smith, Donald
> Cc: [email-masked]'; [email-masked]'; 
> [email-masked]'
Yes elicited tends to imply "caused by".
Adding appear to the statement as Toby did makes it more correct.

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Sep 2009 16:03:40 -0700

Some additional feedback:

- --
2.1 indicates reasons why ICMPs are not reliable; it should include
reasons why ICMPs could be late - so late that, e.g., sequence numbers
aren't relevant.
- --
In Sec 4.1:
   It should be note that as there are no timeliness for ICMP error
   messages, the TCP Sequence Number check described in this section
   might cause legitimate ICMP error messages to be discarded

This should also note that it is also possible to end up acting on ICMPs
that are old even when such checks are in place, depending on the
lateness of the ICMP and the width of the valid sequence number window.
- --
top Page 13, space is missing:
   synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
   CLOSING, LAST-ACK or TIME-WAIT)as "soft errors".  That is, they do
                                  ^
- --
Section 8 would benefit from a summary of the different techniques used
(e.g., parameter checking to drop ICMPs, state checking to drop ICMPs,
etc.) and a description of how each basic technique affects the system -
i.e., they (in general) make the system more robust to deliberate
attacks, but could make the system react less rapidly to legitimate
network errors. This is a deliberate trade-off, and perhaps a reasonable
one, but worth noting, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 Sep 2009 02:11:44 -0300

Hello, Joe,

Thanks for your feedback! Comments in-line....

> reasons why ICMPs could be late - so late that, e.g., sequence numbers

Could you clarify what you have in mind, specificaly? ICMP error
messages being assigned lower priority than normal traffic, or what?
FWIW, routers typically rate-limit ICMP errors...

> lateness of the ICMP and the width of the valid sequence number window.

I have no problem with this. However, the doc tries to address
deliberate attacks rather than ligitimate old packets. That said, if you
still feel this should be addressed in the document, please let me know
and I will incorporate text about this..

>    CLOSING, LAST-ACK or TIME-WAIT)as "soft errors".  That is, they do

Thanks!

                                  ^
> one, but worth noting, IMO.

Will do.

Thanks again!

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 Sep 2009 08:48:25 +0300

> FWIW, routers typically rate-limit ICMP errors...

They are also sometimes forwarded at (much) lower priority, and esp.  
some CE devices have huge buffers that when full can lead to seconds  
of delay. (That's one factor why ICMPs may be arriving much later than  
the corresponding TCP segments, there may be others.

(Who knows if some ITU-T transport network architecture defines a  
centralized "control plane signaling generator box" that sends out  
ICMPs on behalf of an entire network, for example. Yes, this is a made- 
up example.)

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Sep 2009 23:07:53 -0700

> FWIW, routers typically rate-limit ICMP errors...

Routers aren't required to emit ICMP errors on any particular timescale.
They can queue the events and get around to them - whenever. That
includes queues, low priority processing, etc. Regardless of rate
limiting, there's still no requirement about timeliness at all.

> and I will incorporate text about this.

The point is that the solutions tries to deal with deliberate attacks,
but *in doing so* it changes how it reacts to legitimate events -
whether legitimate old packets (above) or other legitimate events that
would otherwise have been ignored (due to state). It's important to note
this change.

Joe

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 09 Sep 2009 10:10:00 -0400

Please find a couple of comments inline.

On 9/9/2009 2:07 AM, Joe Touch wrote:
> They can queue the events and get around to them - whenever.

IMHO, this comment might need some realistic qualification -- "whenever"
seems overly excessive and too dramatic in real life. Routers do not try
to do busywork and delay ICMP generation (exaggeration purposely
intended to counter-balance).

> That

Yes, router architectures get more complex, but so do solutions. In many
architectures, for example, ICMPs are generated by the line-card CPU,
avoiding any central RP delay, and RP<->LC path. The more busy the
router could get, the more switching is done in hardware, and the more
free cycles control-plane CPUs get. My 2¢.

If it feels like déjà vu, this topic was discussed at:
<http://www.ietf.org/mail-archive/web/tcpm/current/msg03623.html>
Joe Touch > Routers are not required to return ICMPs on any particular
Joe Touch > timescale.
thread started at:
<http://www.ietf.org/mail-archive/web/tcpm/current/msg03621.html>

Thanks,

-- Carlos.

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Sep 2009 07:18:24 -0700

> intended to counter-balance).

"whenever" is when routers get to do it. Consider a router that has an
error in its queue to process. A user installs an upgrade and reboots
it, during which it is offline. Or it goes down and comes back for power
reasons. In either case, there is *no* requirement that such errors be
flushed.

Routers sometimes get locked up doing various things. Their control
planes often operate completely independently of the data plane, and
have priorities that can starve various routines that aren't required to
be timely. Errors that get hit with that could end up on the wire
seconds, minutes - *any* time later.

And they'd be *compliant* with FC1812.

> <http://www.ietf.org/mail-archive/web/tcpm/current/msg03621.html>

I raised it several times before. Bob Braden reiterated it in the
microphone line at an IETF a while ago too. It never made it into this
doc, however, and it should.

Joe

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 09 Sep 2009 10:47:00 -0400

Joe,

Thanks for the response, please see inline.

> seconds, minutes - *any* time later.

My point was not about impossibility, but about qualifying these
possibilities with a of tint of (and gauge them with their degree of)
operational realism. Have you (personally or second hand) seen an ICMP
being delayed by minutes?

> And they'd be *compliant* with FC1812.

I think that it should refer to what the specs envision, and not
necessarily to an ICMP delayed several minutes during an upgrade: e.g.,
rate-limit as per <http://tools.ietf.org/html/rfc1812#section-4.3.2.8>;
note that for example the specs even deal with ICMP generation for
bursts of traffic (e.g., traceroute), at
<http://tools.ietf.org/html/rfc4443#section-2.4> item (f).

> doc, however, and it should.

The document says the following; would s/discarded/discarded or delayed/
cover it?

   It is important to note that ICMP error messages are unreliable, and
   may be discarded due to data corruption, network congestion or rate-
   limiting.  Thus, while they provide useful information, upper layer
   protocols cannot depend on ICMP for correct operation.

Thanks,

-- Carlos.

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Sep 2009 08:00:59 -0700

Carlos Pignataro wrote:
...
>    protocols cannot depend on ICMP for correct operation.

That would help there, but it is also useful in other places to indicate
what happens when a legitimate ICMP is delayed, i.e., how that affects
what your algorithm would do.

It's OK to qualify it with "this is unlikely", but IMO it needs to be
discussed with more than a single word in a single paragraph.

Joe

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 09 Sep 2009 11:12:15 -0400

> discussed with more than a single word in a single paragraph.

I think that "this is unlikely" or "this is highly unlikely" would still
be understating the probability (I am curious to see any experienced
example of ICMP being delayed minutes). Redundancy architectures of
routers typically cover the planned upgrade (or even unexpected reload)
scenarios you presented.

Perhaps a separate sentence in that paragraph before the "Thus, " with
some variation of "rate-limiting can delay ICMPs, and some other highly
unlikely theoretical scenarios can compound the delay"?

Thanks,

-- Carlos.

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Sep 2009 08:21:01 -0700

Carlos Pignataro wrote:
...
> unlikely theoretical scenarios can compound the delay"?

You can't rely on something that isn't required. The fact that current
implementations, in current operation, don't do this isn't relevant.

Consider the proposal to resend 'the last packets seen' after a link
outage, to 'tickle' TCP into waking up. That proposal was considered
inappropriate because the router would hold the packet too long to
satisfy requirements. However, if someone were to propose to hold ICMPs
and issue them later, that would be *compliant*.

Protocols aren't just about what happens to work today; they're about
what you can expect to work tomorrow too. Anything that examines the
contents of an ICMP needs to appreciate that those contents do NOT have
to obey timeliness requirements - notably of the protocol being conveyed
as payload. You need to explain what happens when your assumptions are
wrong not because they're often wrong today, but because you cannot know
whether they'll be wrong tomorrow.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 9 Sep 2009 08:57:09 -0700

Jumping in to this thread since I had mentioned it many times earlier
that delayed ICMP's causing issues for seq # check is impractical today.
On the client side validation we can have the following scenarios :-

#1 - ICMP comes in and doesn't match the current segments (or in some
implementations packets) sitting in the retransmission queue, thus the
ICMP is silently dropped. No harm.
#2 - ICMP arrives and it matches the sequence #, this is the usual case.
No harm if false positives are handled correctly.

The cause for concern is the case where the ICMP packet gets delayed for
a long time and the sequence number has wrapped around and the seq # no.
exactly falls in the window of packets sitting in the retransmit queue.
This cam happen only when the data is sent at a very fast rate and such
cases extra checks are necessary. OTOH, if the ICMP packet seq#  falls
outiside (> SNDNXT) in such cases this is for something not yet sent,
discard it. No harm

IMO, this is not an issue at all, these false positives can be handled
with appropriate checks in the code.

Joe has brought this up multiple # of times and I don't really see this
as an issue. The merits of this seq# check far outweigh the de-merits,
if any. If you have extendeded ICMP support then we could check more to
get even more robustness. (example if timestmaps are available one could
make use of it) We have been using the seq# check in our boxes for quite
some time (Fernando's draft mentions many other popular OS'es using this
method) So, far they have been no issues in the field. 

My proposal would be to add some text to what Joe is concerned about,
highlight the fact that it is mostly theoritical and hence should not be
a concern. If needed some quantification can be done, but I really don't
see the point. 

Just my few bits...

-Anantha

> Behalf Of Joe Touch
> Sent: Wednesday, September 09, 2009 8:21 AM
> To: Carlos Pignataro (cpignata)
> Cc: Smith, Donald; 'tcpm Extensions WG'; 'David Borman'; Fernando Gont
> > I think that "this is unlikely" or "this is highly unlikely" would 
> > still be understating the probability (I am curious to see any 
> > experienced example of ICMP being delayed minutes). Redundancy 
> > architectures of routers typically cover the planned 
> upgrade (or even 
> > unexpected reload) scenarios you presented.
> > 
> > some variation of "rate-limiting can delay ICMPs, and some other 
> > highly unlikely theoretical scenarios can compound the delay"?
> 
> You can't rely on something that isn't required. The fact 
> that current implementations, in current operation, don't do 
> this isn't relevant.
> 
> Consider the proposal to resend 'the last packets seen' after 
> a link outage, to 'tickle' TCP into waking up. That proposal 
> was considered inappropriate because the router would hold 
> the packet too long to satisfy requirements. However, if 
> someone were to propose to hold ICMPs and issue them later, 
> that would be *compliant*.
> 
> Protocols aren't just about what happens to work today; 
> they're about what you can expect to work tomorrow too. 
> Anything that examines the contents of an ICMP needs to 
> appreciate that those contents do NOT have to obey timeliness 
> requirements - notably of the protocol being conveyed as 
> payload. You need to explain what happens when your 
> assumptions are wrong not because they're often wrong today, 
> but because you cannot know whether they'll be wrong tomorrow.
> 
> Joe
> iEYEARECAAYFAkqnx90ACgkQE5f5cImnZrvguwCgrm7/fLMiKak8gGb0QYQsROeK
> 5bcAn0fxfPIznaScGG9Tx0oq0OjCHk8x
> =xegI

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Sep 2009 09:04:07 -0700

Hi, Anantha,

> with appropriate checks in the code.

Please just put this in the doc. This issue comes up. It may not affect
this solution, but it is important to include it - to say that it isn't
an impact. I have asked for similar language in the long-delays doc, but
I'm not sure what the impact there is.

...
> a concern. If needed some quantification can be done, but I really don't

No quantification. A version of what's above is what I'm seeking, though
if we're considering everything we never see in the wild theoretical, we
can gut a lot of complexity out of TCP. IMO, this isn't theoretical -
it's *compliant*, and you can make the case that you do no harm when it
happens. That's the point, and that's what needs to be in the doc, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 Sep 2009 17:51:33 -0300

> And they'd be *compliant* with FC1812.

OT, but probably useful for the sake of theoretical discussion: There's
no requirement in the TCP/IP specs that the TTL of packets get
decremented according to the properties of the link on which the packets
will be forwarded. This means that in theory you could forward a packet
on a link that has a delay of 5 minutes (or, say, over quite a few links
that have a delay of one minute, or whatever), and then any assumptions
about "Maximum Segment Lifetime" are invalid (you'd need something like
Delta-t).

And these scenarios would still be compliant with RFC 791, RFC793,
RFC1222, RFC 1812, and others.

Nevertheless, your comment will be addressed in the icmp attacks I-D.

Thanks,