Subject: Fwd: Sec-dir review of draft-ietf-tsvwg-source-quench-04

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 28 Jan 2012 09:35:41 +0000

A SecDir review of this draft (below) has raised one issue that the 
group should be aware of and may wish to comment upon.

We'd value advice on the suggestion:

"Receipt of an ICMP Source Quench message should not be interpreted as 
an attempt to attack the receiver."

- Let's try to quickly resolve this issue. Some things to consider are:

* Silently ignoring ICMP Source Quench messages eliminates the attack
   vector.
* Firewalls/routers/etc can log anything they wish, we don't control that.
* Receipt of an ICMP SQ is unlikely to impact a host system's transport 
anymore, and certainly not one that is updated by this RFC.
* Some legacy equipment (perhaps even vintage) may/do generate SQ 
messages, reacting to the message (by invoking some procedure other than 
log/discard) may break an otherwise working path through this device.

- The current draft says *must* not be interpreted as an attempt to 
attack the receiver, is that right, or do we wish to consider the 
proposal to make this *should* not?

- If you have advice, or wish to offer better text please respond during 
the document last call!

Best wishes,

Gorry
(TSCWG Chair)

-------- Original Message --------
Subject: Sec-dir review of draft-ietf-tsvwg-source-quench-04
Date: Mon, 23 Jan 2012 10:34:41 -0500
From: <[email-masked]>
To: <[email-masked]>,

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document is straightforward and well written.  I just have a couple 
of nits, but think the document is ready otherwise.

Suggest replacing 'must' with 'should' since the discussion is on 
interpretation.
Change from:
Receipt of an ICMP Source Quench message must not be interpreted as an 
attempt to attack the receiver.
To:
Receipt of an ICMP Source Quench message should not be interpreted as an 
attempt to attack the receiver.

It is already clear from the rest of the draft and this section, that 
there is no risk by ignoring ICMP source quench messages, which is done 
by 'virtually all current implementations of TCP'.   Should this say, 
virtually all current implementations of 'IP' or 'TCP' and 'ICMP'?   The 
discussion covers source quench being deprecated (RFC1812) by router 
implementations 20 years ago and now formally deprecates this within TCP.

Thank you,
Kathleen

---

From: Chris Benson <[email-masked]>
Date: Mon, 30 Jan 2012 10:06:32 -0800 (PST)

Hi folks,

I only wish to address the WORD used in the draft.  I think it 
is not a MUST NOT because other information (perhaps about other 
received packets) could be used which in tandem could suggest an 
attack. I therefore agree with the sentiment in general, but
think it should be SHOULD NOT.

With thanks, from Chris Benson.

On Sat, 28 Jan 2012, Gorry Fairhurst wrote:

>>  Date: Sat, 28 Jan 2012 09:35:41 +0000
>>  From: Gorry Fairhurst <[email-masked]>
>>  To:  <[email-masked]>,  <[email-masked]>,
>>      <[email-masked]>, gorry Fairhurst <[email-masked]>
>>  Subject: Fwd: Sec-dir review of draft-ietf-tsvwg-source-quench-04
>>  
>>  
>>  A SecDir review of this draft (below) has raised one issue that the group
>>  should be aware of and may wish to comment upon.
>>  
>>  "Receipt of an ICMP Source Quench message should not be interpreted as an
>>  attempt to attack the receiver."
>>  
>>  * Some legacy equipment (perhaps even vintage) may/do generate SQ messages,
>>  reacting to the message (by invoking some procedure other than log/discard)
>>  may break an otherwise working path through this device.
>>  
>>  - The current draft says *must* not be interpreted as an attempt to attack
>>  the receiver, is that right, or do we wish to consider the proposal to make
>>  this *should* not?
>>  
>>  - If you have advice, or wish to offer better text please respond during the
>>  document last call!
>>  
>>  Best wishes,
>>  
>>  Gorry
>>  (TSCWG Chair)
>>  
>>  The document is straightforward and well written.  I just have a couple of
>>  nits, but think the document is ready otherwise.
>>  
>>  It is already clear from the rest of the draft and this section, that there
>>  is no risk by ignoring ICMP source quench messages, which is done by
>>  'virtually all current implementations of TCP'.   Should this say, virtually
>>  all current implementations of 'IP' or 'TCP' and 'ICMP'?   The discussion
>>  covers source quench being deprecated (RFC1812) by router implementations 20
>>  years ago and now formally deprecates this within TCP.
>>  
>>  
>>  Thank you,
>>  Kathleen
>>  
>>  
>>

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2012 13:08:31 -0800

Hi, all,

> an attempt to attack the receiver."
...
> proposal to make this *should* not?

MUST NOT seems required by MUST silently ignore (section 3). That's what 
"silent" and "ignore" means.

Using "SHOULD NOT" leaves open this misinterpretation, and thus *opens* 
a vulnerability at the receiver to spoofed messages - i.e., it's 
inconsistent with the security implications of this doc, notably:

---
Receipt of an ICMP Source Quench
    message must not be interpreted as an attempt to attack the receiver.
---

In that section, to be clear, we should change:

---
Receivers should not treat reception as an
    exception, error or logged event.
---

to

---
Receivers must not treat reception as an
    exception, error or logged event.
---

Joe