Subject: IESG Comments about ICMPv6 draft: Authentication and Confidentiality of ICMP messages

From: [email-masked]
Date: Thu, 24 Feb 2005 22:38:44 -0600

Hi All,

Allison had the following comment to the ICMPv6 draft as
part of the IESG review:

> 1. IPSec processing considerations about ICMP are enough 
>    different in the bis ESP and AH specs that I think this 
>    document should update to require these (just approved).

I looked at ESP and AH old and bis RFCs.  The section on
how to handle ICMP packets is not part of those RFCs.  The
section "ICMP Processing" was actually part of 2401 and
now 2401bis.  So I guess, we need to modify the text in
ICMP RFC and add 2401bis to the reference list.

I have the following questions/concerns:

- Should 2401bis be a normative reference or informative?
  If normative, can we wait till 2401bis is approved?

- ICMP RFC has a "MAY" requirement for configuring a node
  to ignore unauthenticated ICMP packets but 2401bis has
  a "MUST" requirement for the same thing.  Are we not in
  conflict ?

- ICMP RFC (section 5.1) briefly describes how the ICMP
  packets should be processed in conjunction with ESP/AH
  headers.  2401bis has a section "ICMP processing" (6.1)
  that describes the same thing in great detail.  Should
  ICMP RFC just say that the processing rules are given
  in 2401bis ?

Regards
Mukesh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Feb 2005 17:48:46 +0200 (EET)

>  If normative, can we wait till 2401bis is approved?

Actually, 2401bis has not been approved yet; it is past the first 
round of IESG evaluation, but there are still substantial IESG issues 
to iron out.  It'll take a while.

But even beyond that, 2401bis would be first going to Proposed 
Standard (and maybe recycle to DS later).  This is for DS.  This kind 
of normative reference ("downref") is not procedurally acceptable.

See more below.

>  a "MUST" requirement for the same thing.  Are we not in

Did you mean that the new ICMP RFC requires a configuration knob to be 
able to configure this behaviour (this is how I read 2401bis)?

I don't see a problem there.  In any case, it's a requirement for 
_IPsec_ implementors.

>  ICMP RFC just say that the processing rules are given

This would seem like a good idea -- the key point is figuring out 
whether we can do this would having to put in a Normative Reference to 
IPsec documents :-(.

This may sound weasel-wording, but IMHO it isn't.  While it's useful 
for the ICMP spec to discuss how to mitigate attacks on non-IPsec ICMP 
by the use of IPsec, implementation details of IPsec are in no way 
normative to the ICMP implementer, because the ICMP implementer does 
not even need to implement IPsec if (s)he doesn't want to.  Therefore 
my logic says that an Informative reference should be fine.

..

By the way, one additional ICMP attack that could possibly be included 
in 5.2:

    6. As the ICMP messages are passed to the upper-layer processes, it
       is possible to perform attacks on the upper layer protocols
       (e.g., TCP) with ICMP [TCP-attack].  Protecting the upper layer
       with IPsec mitigates this problem, though the upper layers may
       also perform some form of validation of ICMPs on their own.

Where [TCP-attack] is an informative reference to 
draft-gont-tcpm-icmp-attacks-03.txt.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings