Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

"Zhenghui (Marvin)" <marvin.zhenghui@huawei.com> Tue, 14 March 2017 03:40 UTC

Return-Path: <marvin.zhenghui@huawei.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C491293F5 for <dots@ietfa.amsl.com>; Mon, 13 Mar 2017 20:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cC4SsUi2LjnG for <dots@ietfa.amsl.com>; Mon, 13 Mar 2017 20:40:04 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F39C129C36 for <dots@ietf.org>; Mon, 13 Mar 2017 20:40:03 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIV08569; Tue, 14 Mar 2017 03:40:01 +0000 (GMT)
Received: from SZXEMI401-HUB.china.huawei.com (10.82.75.33) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Mar 2017 03:39:57 +0000
Received: from SZXEMI507-MBX.china.huawei.com ([169.254.8.223]) by SZXEMI401-HUB.china.huawei.com ([10.82.75.33]) with mapi id 14.03.0235.001; Tue, 14 Mar 2017 11:39:52 +0800
From: "Zhenghui (Marvin)" <marvin.zhenghui@huawei.com>
To: "Teague, Nik" <nteague@verisign.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking
Thread-Index: AQHSnBBq4ZM58GBcQp6mg2Ssqy0muqGTsGKg
Date: Tue, 14 Mar 2017 03:39:52 +0000
Message-ID: <F8F4995E43962F4996B280E9678CED00015389AE@SZXEMI507-MBX.china.huawei.com>
References: <0ED35034-E1EC-4748-9153-BEBBBD2B0DAE@verisign.com>
In-Reply-To: <0ED35034-E1EC-4748-9153-BEBBBD2B0DAE@verisign.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.135.87.2]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58C76612.007F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.223, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: dfe222c9357e57c7cf131af75aa580cd
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Oz01xicHCv8MHO8rV4hY4kjgpLk>
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2017 03:40:06 -0000

Thanks Nik, your comment is very helpful.

We do need to consider the case of asynchronous/asymmetric traffics.

Best Regards,
Zhenghui (Marvin)


-----Original Message-----
From: Teague, Nik [mailto:nteague@verisign.com] 
Sent: Monday, March 13, 2017 11:42 PM
To: Zhenghui (Marvin) <marvin.zhenghui@huawei.com>; dots@ietf.org
Subject: Re: [Dots] draft-fu-dots-ipfix-extension revised into draft-fu-dots-ipfix-tcp-tracking

Marvin hi,

Some feedback on the mechanism…

Many networks deploy architectures where separate perimeter routers connect to any number of providers.  Traffic, as a result, is often asynchronous – i.e. the best path _out_ is not always the best path _in_ (for any number of reasons… bgp is policy based remember).  Therefore, a device that handles inbound packets for a flow may not be the same one dealing with outbound.  This means your IE’s may be rendered generally useless depending upon whether or not you, somehow, pin traffic to a path (which would probably be vulnerable then to exploitation).  There have been a few implementations that try and stitch flows together (ibm’s qflows come to mind) but these are generally done at the collection/analysis layer vs locally on a router.

Thanks,

-Nik

On 13/03/2017, 07:37, "Dots on behalf of Zhenghui (Marvin)" <dots-bounces@ietf.org on behalf of marvin.zhenghui@huawei.com> wrote:

    Hello DOTS WG,
     
    We have submitted a draft draft-fu-dots-ipfix-tcp-tracking-00, which is the succession of draft-fu-dots-ipfix-extension-01.
    
    The original draft has been reviewed internally. As a result,  the IPFIX Information Elements inside the draft have been revised, and some of the IEs are removed.
     
    However, we’ve realized what our draft intends to do is not what currently DOTS WG is focusing on.
    So, we’d like to hear from the WG, is that some pointers can be given on the next step of the draft, or where we can continue the discussion of the issue that the draft addresses.
     
    We submitted this draft to DOTS because IPFIX WG had been closed, and DOTS was the best match we found.
     
    Thanks.
     
    Marvin Zhenghui
    Best Regards