[Int-area] Proposal to update RFC 2890 - Key and Sequence Number Extensions to GRE

Sabri Berisha <sabri@cluecentral.net> Mon, 20 March 2017 19:13 UTC

Return-Path: <sabri@cluecentral.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61831316AF for <int-area@ietfa.amsl.com>; Mon, 20 Mar 2017 12:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7fIY3e0FwuSD for <int-area@ietfa.amsl.com>; Mon, 20 Mar 2017 12:13:16 -0700 (PDT)
Received: from mail.cluecentral.net (mail.cluecentral.net [195.16.84.32]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105081316A5 for <int-area@ietf.org>; Mon, 20 Mar 2017 12:13:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.cluecentral.net (Postfix) with ESMTP id 05159400219 for <int-area@ietf.org>; Mon, 20 Mar 2017 12:16:15 -0700 (PDT)
Received: from mail.cluecentral.net ([127.0.0.1]) by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id IRNBhUGBhYkg for <int-area@ietf.org>; Mon, 20 Mar 2017 12:16:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.cluecentral.net (Postfix) with ESMTP id 4346940021C for <int-area@ietf.org>; Mon, 20 Mar 2017 12:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at mail.cluecentral.net
Received: from mail.cluecentral.net ([127.0.0.1]) by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b_8L-teK13Ks for <int-area@ietf.org>; Mon, 20 Mar 2017 12:16:10 -0700 (PDT)
Received: from mail.cluecentral.net (mail.cluecentral.net [195.16.84.32]) by mail.cluecentral.net (Postfix) with ESMTP id 1642C400219 for <int-area@ietf.org>; Mon, 20 Mar 2017 12:16:10 -0700 (PDT)
Date: Mon, 20 Mar 2017 12:16:09 -0700
From: Sabri Berisha <sabri@cluecentral.net>
To: int-area@ietf.org
Message-ID: <1986249538.8510.1490037369964.JavaMail.zimbra@cluecentral.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_8509_606393501.1490037369962"
X-Originating-IP: [195.16.84.16]
X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - GC56 (Win)/8.6.0_GA_1153)
Thread-Topic: Proposal to update RFC 2890 - Key and Sequence Number Extensions to GRE
Thread-Index: wjpxPvvJs0I85WBHuvUhMPiuyF+aqA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Oc6z_d5KQAuFnvCvC4IX4nRJoI8>
Subject: [Int-area] Proposal to update RFC 2890 - Key and Sequence Number Extensions to GRE
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 19:13:18 -0000

Hello IETF workgroup members, 

Apologies if this is sent to the wrong workgroup. 

Recently, I was asked to investigate an issue involving packets being transmitted out of sequence by a flagship routing product of a major vendor of internet backbone routers. Long story short, we observed that the chipset involved would indeed process the frames out of sequence if the following circumstances were met: 

- Small frame size; 
- GRE tunnel with packets with and without the sequence number bit set interleaved; 
- Bursty traffic circumstances (a small frame not carrying the sequence number bit set, arriving within 11 microseconds of a frame with a sequence number set); 

In this case, the key field was populated consistently at all times with the same key identifier. The forwarding chip in this case, took the sequence bit into consideration when determining whether or not it was part of a flow. The vendor addressed the issue by not looking deeper into the frame if the packet is not TCP or UDP. 

Obviously, I found it interesting that a GRE implementation would set the sequence number on some frames in the same flow, but not on others. However, I found that RFC 2890 explicitly allows this in section 2.2: 
"Note that packets without the sequence bit set can be interleaved with packets with the sequence bit set." 
I'm too junior to know the exact reason of why this was allowed, but I'd like to propose an update to RFC 2890, with (apart from all the standard text) the following: 
3. Consistent use of the Key field 
Once the encapsulator elects to insert the Key field for a designated traffic flow, the encapsulator MUST insert the same Key identifier for all frames transmitted as part of that traffic flow. 
4. Consistent use of the Sequence Number field 
Once the encapsulator elects to insert a Sequence Number for a designated traffic flow, the encapsulator MUST insert a Sequence Number for all frames transmitted as part of that traffic flow. 
The encapsulator MUST increment the Sequence Number by 1 for each transmitted frame. The encapsulator MUST NOT interleave frames without the Sequence Number set with frames with the Sequence Number set. 

If ratified as a standard by this working group, it would mandate consistent use of the sequence number fields for the entire duration of a flow. The implementer would make a choice at the initial transmission of the first frame whether or not to use sequence numbers. I have a draft ready, written using the MS Word template, but I thought I'd not poison the inboxes of all subscribers of this mailing list. 

Thanks, 

Sabri