Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)

Curtis Villamizar <curtis@ipv6.occnc.com> Fri, 17 January 2014 20:28 UTC

Return-Path: <curtis@ipv6.occnc.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771411AC3FA; Fri, 17 Jan 2014 12:28:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEyVjjnDGtlV; Fri, 17 Jan 2014 12:28:33 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7021A802D; Fri, 17 Jan 2014 12:28:32 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HKSJP6065706; Fri, 17 Jan 2014 15:28:19 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401172028.s0HKSJP6065706@maildrop2.v6ds.occnc.com>
To: Saku Ytti <saku@ytti.fi>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Fri, 17 Jan 2014 18:33:07 +0200." <20140117163307.GA4577@pob.ytti.fi>
Date: Fri, 17 Jan 2014 15:28:19 -0500
Cc: mpls@ietf.org, lisp@ietf.org, tsvwg@ietf.org, ietf@ietf.org
Subject: Re: [mpls] [tsvwg] [lisp] draft-ietf-mpls-in-udp was RE: gre-in-udp draft (was: RE: Milestones changed for tsvwg WG)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 20:28:35 -0000

In message <20140117163307.GA4577@pob.ytti.fi>
Saku Ytti writes:
 
> On (2014-01-13 14:11 -0500), Curtis Villamizar wrote:
>  
> > One of the reasons that IPv6 (rfc2460) dropped the header checksum
> > that was in IPv4 is that with link layers all doing FCS it served no
> > purpose.  For the same reason TCP and UDP checksums server no purpose.
>  
> One datapoint from today. Peering router has 4xLACP to core and in one of
> these LACP members it is sometimes mangling packets during send and FCS is
> being calculated for this mangled data.
> All egress PE boxes start logging errors (maybe 1 error per 30min), because
> they check IP checksum, which is now incorrect.
>  
> Router is latest generation service provider router from major vendor running
> recent software and affected router is logging no errors.  Can't imagine
> when, if ever, would this issue have been found without IP checksums.
>  
> -- 
>   ++ytti
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls


This sounds like a router acting as a host for the given packet.  The
forwarding data paths in routers are usually protected.  If the router
was forwarding and mangled packets, that speak well for the router
vendor since the major vendors claim to protect their data paths from
this sort of thing.  Less so for the path from the route processor.

If this was originated at the router it would also be caught if AH was
enabled.  Were these unauthenticated control plane packets?

You've made a good anecdotal case for keeping TCP and UDP checksums.

Curtis