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

From: [email-masked]
Date: Sun, 27 Feb 2005 03:13:17 -0600

Pekka,

Comments inline..

> 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.

Then what is the best way to accomodate Allison's comment :(

> 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)?

Sorry for not being clear.  The current ICMPv6 draft says 
that an implementation "MAY" provide a knob to control
this behavior (accept or reject the unauthenticated ICMPv6 
msgs).  On the other hand, 2401bis says that an implementation
"MUST" provide a knob to control this behavior.

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

If providing this knob is a requirement for ONLY IPsec 
implementors, why are we mentioning it (as a MAY requirement)
in the ICMPv6 draft ?

> 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.

Are you suggesting that the ICMPv6 draft should say that the 
security related processing details are described in 2401bis
and put 2401bis as a informative reference.

or

you are suggesting to keep the wording as it is in the
current draft ?

> 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.

Interesting.  I will try to add this to the next rev.

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: Sun, 27 Feb 2005 12:09:10 +0200 (EET)

Hi,

(Btw, maybe we could add "This document Updates RFC 2780." in the 
Introduction, satisfying Allison's that particular comment.)

> "MUST" provide a knob to control this behavior.

Now that there is a document which describes how to deal with ICMPv6 
and IPsec, this document should probably have as small amount of 
normative text on IPsec as possible.

Some informal text, helping the ICMPv6 implementers to understand the 
IPsec processing issues, should be still OK.

> implementors, why are we mentioning it (as a MAY requirement)

Let's remove the mention.

[...]
> and put 2401bis as a informative reference.

Yes, though it has to be worded carefully as not to be seen as a red 
flag. It should probably be stated like:

  "IPsec RFCs describe the IPsec processing, including ICMPv6 messages"

instead of:

  "IPsec processing of ICMPv6 messages is described in IPsec RFCs"

(IMHO, the latter may confuse the reader to think that IPsec 
processing of ICMPv6 messages should be described in _this_ spec and 
IPsec specs should be a normative reference.)

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