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

[Chris Benson <[e-mail]>]

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 <[e-mail]>
>>  To:  <[e-mail]>,  <[e-mail]>,
>>      <[e-mail]>, gorry Fairhurst <[e-mail]>
>>  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.
>>  
>>  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: <[e-mail]>
>>  To: <[e-mail]>,
>>  
>>  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
>>  
>>  
>>