rfc1122 (host requirements) says:
An ICMP error message MUST NOT be sent as the result of
receiving:
...
*a datagram destined to an IP broadcast or IP multicast
address, or
*a datagram sent as a link-layer broadcast, or
> the attacker was willing to be caught. Because redirects can't be forwarded
> from off-link (the hop limit must be 255 when received) there is no way for
> an attacker to mount a redirect based attack unless the attacking system
> is on the same link as the target.
Correct. And like you say, i
Itojun,
>
> ICMPv6 redirect has similar issue as ICMPv6 too big, and we can remedy
> the problem by using similar "upper limit" technique. could you please
> give some more detail with parameter problem?
>
I am not sure how ICMPv6 redirects could be used in such a DoS at
> Why SHOULD they respond ? Having all recipient of a multicast stream respond
> to something is not a good idea - you don't need an attack, as you would be always
>only
Well... because RFC 2463 section 2.4 point (e.2) wants you to?
The RFC names two exceptions to the never-respond-to-multicas
Jari Arkko wrote:
> >There are two possible meaning for "DoS using ICMPv6 too big".
> > - victim node cannot use larger MTU size for destinations, because of
> > forged ICMPv6 too big from a bad guy.
> > since IPv6 minimum MTU is 1280, the situation is much better
> > than IPv4 case.
> > -
>There are two possible meaning for "DoS using ICMPv6 too big".
> - victim node cannot use larger MTU size for destinations, because of
> forged ICMPv6 too big from a bad guy.
> since IPv6 minimum MTU is 1280, the situation is much better
> than IPv4 case.
> - if the victim node is careless
Date:Wed, 20 Dec 2000 07:31:31 -0800 (PST)
From:Michael Thomas <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| I tend to doubt that sending the AH or ESP headers up the
| stack is especially useful.
I think what you mean is that applications are unlikel
The minutes for last weeks IPng meeting can be found at:
http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-dec2000.txt
Please send corrections to me.
Happy Holidays,
Bob
IETF IPng Working Group Mailing List
IPn
