Re: [Dots] Data Channel ACL fragments

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 13 April 2018 12:25 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.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 A16B51242F5 for <dots@ietfa.amsl.com>; Fri, 13 Apr 2018 05:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com
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 gATFjbVKflFg for <dots@ietfa.amsl.com>; Fri, 13 Apr 2018 05:24:59 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD9012420B for <dots@ietf.org>; Fri, 13 Apr 2018 05:24:58 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1523622298; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Office365-Filtering-Correlation-Id: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=A INDoxrQK9LwAdhUwKnVSTIfVfT+gxf0ibZLVYIjrf g=; b=C15CXI3lKxgiRVkb/pnH8lclUDNKw/IgDGRUieaTcjga AR8N4hEhHdE71oLkwMz9drs0/wMGaFoIKTX6AAdpFYaH7Wz/dW A7cpIsP+qLRIgUByhISdaIjhReZDkyk7Wrq5uB8A1nnbGq30TA AFPVE0+xXO9hF1cv2NOe8OxzMUo=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2776_4f6f_3d04240f_bb5d_4c89_8d55_401be55bc519; Fri, 13 Apr 2018 07:24:57 -0500
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 06:24:35 -0600
Received: from DNVEX10N01.corpzone.internalzone.com (10.44.82.192) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 13 Apr 2018 06:24:35 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEX10N01.corpzone.internalzone.com (10.44.82.192) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 13 Apr 2018 06:24:34 -0600
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 13 Apr 2018 06:24:33 -0600
Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1716.namprd16.prod.outlook.com (10.172.28.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.9; Fri, 13 Apr 2018 12:24:33 +0000
Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::4430:6104:630b:a067%2]) with mapi id 15.20.0675.014; Fri, 13 Apr 2018 12:24:32 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Data Channel ACL fragments
Thread-Index: AdPMHAMfDWFlXvb3TSeAr5MVkYUzIgAA3pEAAAKPJoAAIuTfcAADWaQAAADopUAAyEgtgAACNjegABYTlwAAEYzK0AAHIEOAAAC6rLAAAzlEAAAAT7KgAAMBYAAAjfWr8AADyrCAAAQ1fKA=
Date: Fri, 13 Apr 2018 12:24:32 +0000
Message-ID: <BN6PR16MB1425DFC5475D456042FD6F11EAB30@BN6PR16MB1425.namprd16.prod.outlook.com>
References: <016401d3cc1c$03321200$09963600$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF7F97@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01a701d3cc29$ba915b10$2fb41130$@jpshallow.com> <BN6PR16MB14257B016ED90BC00A9BA3E5EABB0@BN6PR16MB1425.namprd16.prod.outlook.com> <007501d3ccc2$b49f0b00$1ddd2100$@jpshallow.com> <BN6PR16MB1425B5115EC9C603E5E7945AEAB90@BN6PR16MB1425.namprd16.prod.outlook.com> <021301d3cfe7$77e5cbe0$67b163a0$@jpshallow.com> <BN6PR16MB142560DE045B75F16CB4E981EABF0@BN6PR16MB1425.namprd16.prod.outlook.com> <02b001d3d048$a2c68be0$e853a3a0$@jpshallow.com> <BN6PR16MB1425D028388461917E44A9F4EABE0@BN6PR16MB1425.namprd16.prod.outlook.com> <000001d3d0ab$547dec40$fd79c4c0$@jpshallow.com> <DM5PR16MB14363A5B24501ED8ABFB0903EABE0@DM5PR16MB1436.namprd16.prod.outlook.com> <007701d3d0bb$2404c330$6c0e4990$@jpshallow.com> <DM5PR16MB143609A08263017E97C71A17EABE0@DM5PR16MB1436.namprd16.prod.outlook.com> <00a801d3d0c8$67315800$35940800$@jpshallow.com> <BN6PR16MB142519B30BC7F44E332B7077EAB30@BN6P R16MB1425.namprd16.prod.outlook.com> <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com>
In-Reply-To: <00e901d3d30f$687eb1a0$397c14e0$@jpshallow.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.0.200.100
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR16MB1716; 7:RTbd6bbkkbP4ujBfnmm5XQBftKSzT7ovH7HG2yBF+D44bgrQ6uICbkw4gXiArgJ5oCin75X5FjfgIdV7tmtxI1FVrZDGvXWzAgOxLQprcoHeL2AfWclt974ssU+8KYk23/YkC0ZhWRUYzKa6lWfvFGxWkWgi8ae7Ply98b3o2I7Igxzyn4UNgsg+/t3w9fiD/hnfM9CGKhJjJq7k7kVN2qkNAHWCzQzdaUu1XuR/5Wb5rCqssQW+qtJhWxA1WLwI
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1716;
x-ms-traffictypediagnostic: BN6PR16MB1716:
x-microsoft-antispam-prvs: <BN6PR16MB17163D7A9F6CEFC8FECE9272EAB30@BN6PR16MB1716.namprd16.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155)(123452027830198);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231232)(944501327)(52105095)(93006095)(93001095)(3002001)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR16MB1716; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1716;
x-forefront-prvs: 0641678E68
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(376002)(39380400002)(189003)(199004)(69234005)(32952001)(486006)(11346002)(446003)(81156014)(81166006)(97736004)(5250100002)(8676002)(476003)(80792005)(2501003)(6436002)(2900100001)(54896002)(25786009)(186003)(19609705001)(106356001)(86362001)(53946003)(6306002)(9686003)(236005)(110136005)(6246003)(8936002)(55016002)(53936002)(2201001)(316002)(99286004)(7696005)(14454004)(478600001)(72206003)(33656002)(66066001)(3660700001)(229853002)(102836004)(105586002)(5660300001)(26005)(76176011)(74316002)(68736007)(7736002)(790700001)(6116002)(3846002)(6506007)(2906002)(59450400001)(3280700002)(93886005)(53546011)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1716; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: IZg1BqmkZ6FmRD3jncfKSgmIQBuz0QDEHNaAR86yml6eSVRu/LSH0NlQIXCWzkqjngNgjmfd68veC+gBFYyrrdH9VbTo3bWIQ571fbYYkPDTKp937fdqSnCUBL+Lh/YOTxL3zhVwHhrZq1IPFAEEtwJFeCksEFY9qf5NonMtGgFP1pKy89HK3dp4w4cf5EqnW2iygzSsCbXYFeo1dEAc8A==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425DFC5475D456042FD6F11EAB30BN6PR16MB1425namp_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 396e64fa-37ec-4df3-fe6e-08d5a1398331
X-MS-Exchange-CrossTenant-Network-Message-Id: 396e64fa-37ec-4df3-fe6e-08d5a1398331
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2018 12:24:32.7217 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1716
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6264> : inlines <6559> : streams <1783905> : uri <2624806>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/utq8M2ABxz9BQEU3tt7uXHcMAFY>
Subject: Re: [Dots] Data Channel ACL fragments
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 13 Apr 2018 12:25:01 -0000

[Jon6] - Yes - I stand corrected, your ordering is correct.  A2 no longer needs destination-port.

Yup. The summary of our discussion is to use the flags defined in netmod-acl-model to drop fragments (both initial and non-initial), and v4-fragments and v6-fragments and the associated text added to drop non-initial fragments discussed in Section 4.1 will be removed from the draft.

Cheers
-Tiru

From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, April 13, 2018 3:39 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL fragments

Hi Tiru,

See inline [Jon6]

Regards

Jon

From: Dots [mailto: dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 13 April 2018 10:03
To: Jon Shallow; mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; dots@ietf.org<mailto:dots@ietf.org>
Subject: Re: [Dots] Data Channel ACL fragments

Hi Jon,

Please see inline [TR4]


From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com<mailto:TirumaleswarReddy_Konda@mcafee.com>]
Sent: 10 April 2018 07:10
To: Jon Shallow; mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; dots@ietf.org<mailto:dots@ietf.org>
Subject: RE: [Dots] Data Channel ACL fragments

[Jon2] The "flags->fragment" definition is ambiguous for an ACE (but valid as to whether to allow a packet to get fragmented or not - is that really a ACE?) which I would like to use.

[TR] I don't get it. What purpose does it serve to create a ACE rule using "fragment" bit ?
[Jon3] Agreed - This definition has not been thought through for an ACE.  I think they have just emulated the DF bit in RFC791 as this general flags definition is the same as for the flags in RFC791.

[TR2] You may want to inform the authors of netmod-acl draft, surprisingly BGP flowspec also uses "fragment" bit.
[Jon4] On my ToDo list for a clean solution.  But we do now have a solution - see below.


"Flags->more" definition covers all fragments but the last fragment. "Offset" is unfortunately not a range, but otherwise would get used for the final fragment.
~jon2

[TR] It looks like two ACE entries are required to drop all the fragments ("flags->more" set to 1 in the first ACE and "flags->more" set to 0 in the second ACE). How to use the "Offset"  field for the final fragment ?

[Jon3] I read "flags-more" to refer to the IP_MF in the IP header (RFC791 MF or more-fragments flag).  This is set for all fragments apart from the final (as in last part of packet, not the order in which they are sent - fortunately that early decision to send them in the wrong order was phased out, but still there in some legacy systems!)

[TR2] Yes, why can't "flags->more" be set to 0 as one ACE entry to drop the final fragment along with "flags->more" set to 1 to drop the first fragment as another ACE entry so as to drop all fragments to the target ?
[Jon4] If "flags->more" is configured and it is configured with a value of 0, this will match not only the final fragment, but also a non-fragmented packet.  If "flags->more" is not configured, then this will match a non-fragmented packet only.

[TR3] net-mod-acl says "Setting the value to 0 indicates this is the last fragment, and setting the value to 1 indicates more fragments are coming.". I think it means, if "flags->more" is set to zero and offset is not zero then it indicates this is the last fragments; the flags can be used in isolation without comparing if offset value is zero or non-zero. We should check with netmod-acl authors for confirmation.

[Jon5].  The netmod-acl text for flags and offset is effectively a word for word copy out of RFC791 3.1 Internet Header Format.  So I think it is meant to be interpreted as being an exact match for the same - including the offset specific value.

  Flags:  3 bits

    Various Control Flags.

      Bit 0: reserved, must be zero
      Bit 1: (DF) 0 = May Fragment,  1 = Don't Fragment.
      Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.

          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+

  Fragment Offset:  13 bits

    This field indicates where in the datagram this fragment belongs.

    The fragment offset is measured in units of 8 octets (64 bits).  The
    first fragment has offset zero.


----

Versus

----
    leaf flags {
      type bits {
        bit reserved {
          position 0;
          description
            "Reserved. Must be zero.";
        }
        bit fragment {
          position 1;
          description
            "Setting value to 0 indicates may fragment, while setting
             the value to 1 indicates do not fragment.";
        }
        bit more {
          position 2;
          description
            "Setting the value to 0 indicates this is the last fragment,
             and setting the value to 1 indicates more fragments are
             coming.";
        }
      }
      description
        "Bit definitions for the flags field in IPv4 header.";
    }

    leaf offset {
      type uint16 {
        range "20..65535";
      }

      description
        "The fragment offset is measured in units of 8 octets (64 bits).
         The first fragment has offset zero. The length is 13 bits";
    }

[Jon4] So, a L4 ACE without "flags->more" defined and "allow", followed by an ACE with "flags->more" = 1 and "drop", followed by an ACE with "flags->more" = 0 and "drop" will cause all fragmented packets to get dropped, but still allow through the non-fragmented packet.  So, we have a solution for
"allow all traffic to port 53, but drop all fragmented packets".

[TR3] I don't think the above solution will work. In the above line, I think you  meant L3 ACE, and the first fragment will match the first entry and is allowed.

[Jon5]No, the first ACE is a L3/L4 match.  If you have (a1 allows through all non-fragmented packets, a2 & a3 drops all fragmented packets) the following

[TR4] The first fragment will have both L3 and L4 information, and matches a1 and is allowed, but if the order is changed to a3, a1 and a2 (a3 will drop all fragments except last-fragment, the last fragment will not have L4 info, so will not match a1 but will match a2 and get dropped).

[Jon6] - Yes - I stand corrected, your ordering is correct.  A2 no longer needs destination-port.
~jon6

-Tiru

...
{
       "aces": [{
                                     "ace": {
                                                    "name": "a1",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "destination-network": "1.2.3.0/24"
                                                                   },
                                                                   "udp": {
                                                                                  "destination-port": 53
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "accept"
                                                    }
                                     }
                      },
                      {
                                     "ace": {
                                                    "name": "a2",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "flags": {
                                                                                                 "destination-network": "1.2.3.0/24",
                                                                                                 "more": 0
                                                                                  },
                                                                                  "udp": {
                                                                                                 "destination-port": 53
                                                                                  }
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "drop"
                                                    }

                                     }
                      },
                      {
                                     "ace": {
                                                    "name": "a3",
                                                    "matches": [{
                                                                   "ipv4": {
                                                                                  "flags": {
                                                                                                 "more": 1
                                                                                  }
                                                                   }
                                                    }],
                                                    "actions": {
                                                                   "forwarding": "drop"
                                                    }
                                     }
                      }
       ]
}
...
[Jon5] It will work

-Tiru

~jon4

-Tiru

[Jon3] But as the final fragment of the sequence could have any offset, the use of the offset field is not that helpful here.  Even if we do go with our DOTS fragments definition (but widened to cover all fragments), we still cannot generate a netmod-acl entry for onward processing by an upstream mitigator.

[Jon3] FYI, for Juniper, you just need to set 'first-fragment' and 'is-fragment' in their ACL.  BGP FlowSpec does support fragmentation detection properly (RFC5575 Type 12 Fragment).


-Tiru