Jari,
Your points are valid. See my comments inline..
> The primary problem with this is that while you may know well your
> peer and even be able to set up a security association with him, it
> may not be easy to set up security associations with all the routers
> (and their operators) in between. Perhaps you should mention something
> about this.
You are right but there is no solution to that problem. What is the
purpose of mentioning that ? How exactly do you want this to be
mentioned ? Some proposed text would be helpful.
> Actually, the point about the checksum may have been relevant.
> I think the attack you are describing here is that someone in
> the middle change the destination address of an ICMP message,
> right? ESP does not protect the IP header, but the fact that the
> addresses from the header are included in the pseudo-header that
> is calculated into the checksum helps. The checksum is covered
> by ESP, so that can not be changed. Anyway, that protection may
> not be quite as strong as AH/ESP gives you otherwise. Presumably
> you would have to test for 2^15 different fake addresses before
> you found one that would give the same checksum value, no?
You are right. What about changing the text to the following ?
=====
2. ICMP messages may be subject to actions intended to cause the
message or the reply to it go to a destination different than the
message originator's intention. The protection against this
attack can be achieved by using the Authentication Header
[IPv6-AUTH] or the Encapsulating Security Payload Header
[IPv6-ESP]. Authentication Header provides the protection against
change for the source and the destination address of the IP
packet. Encapsulating Security Payload Header does not provide
this protection but the ICMP checksum calculation includes the
source and the destination addresses and the Encapsulating
Security Payload Header protects the checksum. Therefore, the
combination of ICMP checksum and the Encapsulating Security
Payload Header provides the protection against this attack. The
protection provided by the Encapsulating Security Payload Header
will not be as strong as the protection provided by the
Authentication Header.
=====
> There may be some additional ICMP issues related to DoS that you
> should mention. There are two exceptions in the multicast rule
> e.2 in Section 2.4. In theory, you could cause a very large number
> of nodes to send you Packet Too Bigs or Parameter Problems. For
> instance, just send a multicast packet with an unknown option marked
> as mandatory. Fortunately, it turns out that its relatively hard to
> get the multicast routers to carry your fake multicast packet unless
> you are on the correct multicast path, i.e. very near the legitimate
> sender. But perhaps you should say something about this too.
If a malicious router sends this multicast packet with its own address
as the source address then it is causing a DoS for itself. That is
certainly NOT what the malicious router would like to do.
If this malicious router sends this multicast packet with the source
address of a legitimate multicast source then it might cause a DoS
attack to the multicast sender. This is harmful.
Can ESP/AH protect the sender against this attack ? Yes if the sender
is not accepting un-authenticated ICMP packets.
Did I get this right ? If yes, I will try to add some text about this
in the draft. If no, would you please send me some text for this ?
Thanks !
- Mukesh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
