But there's no reason to believe that the L2 is the same as you enter
the tunnel. You're going through a router, often to a different link
layer. The L2 overhead is stripped off and replaced.
Bert
From: Alex Conta [mailto:[EMAIL PROTECTED]
Se
Another point to note is this. In the case that a packet checksum/hash is used,
a corrupted packet gets dropped on its way, whereas without such a
checksum/hash it is dropped at the destination. Thus additional network
resources are consumed. All this is assuming that layer 2 CRC has been
circu
Hi Iljitsch,
I agree with you. However if you take note of RFC4301 - the IPsec base
RFC, the AH has been downgraded to a MAY support. So not all machines
will support AH. I agree we can do without checksum, am just trying to
fill in when I feel there is some additional information that
discussion
Hi Iljitsh,
You have a point when you say that if a malicious router could toggle
some bits, it could as well drop the packet.
However there is one small part you miss. In the above case the router
can only affect traffic going through it. It could be an attack if
toggling bits on the flows throu
On 1 feb 2008, at 16:12, Rahim Choudhary wrote:
> Now if the change is in the muteable fields (DSCP, TTL) then no
> IPSec measure seems to be able to detect that. This could be a
> vulnerability that either causes the packets to drop on the way (TTL
> manipulation) or assigns them to the wro
Yes I meant it in the sense Wishwas explained it. And I also meant it in the
sense of someone maliciously toggling bits. Let me say a word about the latter.
Assuming that layer 2 CRC will be kosher after the bits have been maliciously
toggled in the mutable fields of the front IPv6 header.
I am not seeing the problem.
The "non-secure IPv6 link" you're mentioning is a "virtual link", over a
"real" physical link. The "real" physical link, the "real" L2, provides
the error detection, which uncovers packet errors in the IPv6 tunnel
packets, like on any other IPv6 packet.
-Origi
On 1 feb 2008, at 1:59, Vishwas Manral wrote:
> For ESP (RFC4303) the ICV does not cover the outer IP header at all
> the mutable field or not. For AH (RFC4302) however the outer IP header
> is covered for the ICV calculation.
Yes. So if you want to cryptographically protect your header, either
