On Thu, Mar 27, 2014 at 4:38 PM, Tom Herbert <[email protected]> wrote:
> > The CRC protects the entire frame till it gets to a router. Once in the > > router, it's the responsibility of the router to maintain packet > integrity > > and not introduce errors via an internal checksum or some other > mechanism. > > A similar issue exists with MPLS labels used for tenant identification. > > > > If we don't trust the router, then we have a problem. IPv6 lacks a > header > > Right, I don't trust routers :-). Hardware fails, cosmic radiation > zaps bits, software bugs occur, etc. A cursory look at our network > currently shows that TCP checksum errors between internal machines are > very rare but not zero (a couple hundred instances a day throughout > the network on average). However, on a bad day, when hardware or > software is failing, we have seen these numbers go way up. So, to be > robust, we still need to consider the network unreliable and not error > free-- this remains a fundamental operational characteristic of IP. > > > checksum and I'm not aware of many routers that will compute the TCP > > checksum in order to validate the integrity of the IPv6 destination > address > > before delivering it to a host. > > > The IP addresses are part of pseudo header (RFC 2460) and are > validated in the TCP checksum, so simple corruption of addresses would > be detected at the receiving host. > It would be (that was why I brought up the TCP checksum), but from a security standpoint, unless routers validate it before delivering the packet to the host, that's too late. > > I would point out that we don't really trust the TCP checksum either! > For any serious data center application (like those that carry real > user data), we need a much stronger end to end CRC over the data (like > in iSCSI, RDMA) if not actual packet security like in IPsec. Because > of the sensitivity of vni, I tend to think it is critical to get right > so a stronger mechanism is warranted. > I don't know if I agree or not with respect to protecting just the VNI. Off the top of my head, I want to disagree, since MPLS VPNs seem to have been doing OK. But maybe things are different with this protocol... Anoop
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
