Re: [Idr] My mic comments on security

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Thu, 25 July 2019 21:50 UTC

Return-Path: <sajassi@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EC212029E; Thu, 25 Jul 2019 14:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PaGkLvFk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lN6jf0Wy
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 dTJ5dt2JQ6z7; Thu, 25 Jul 2019 14:50:57 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD96120295; Thu, 25 Jul 2019 14:50:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6626; q=dns/txt; s=iport; t=1564091457; x=1565301057; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u3jkf/lWwGGLNFXqDhCDqDkMmWSHNN2BwhK95ZAnhTc=; b=PaGkLvFkCdnXqpWHlkV2+GFCbYP6njKp3E9f/a/gJr98vvYvlbPaOItr +NXHuf0JFZD3nuVbevALsoWJtJQXKcXJ8tASaawJxGPTlPb76egxFu9cG 2mHsIfAsXOy7B52bopMaJkZJXDgScQXR9EUzstuPDl4Tn1I9oVfzGkrYU w=;
IronPort-PHdr: 9a23:PaGtPxd/uIwYVXalo+m/urG5lGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFnpnwd4TgxRmBceEDUPhK/u/dCU4Fd9ZVXdu/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AXAADRIzpd/5NdJa1mGwEBAQEDAQEBBwMBAQGBUwYBAQELAYFDUANtVSAECyoKhBODRwOEUogtmi2BLoEkA1QJAQEBDAEBGAsKAgEBhEACF4JHIzQJDgEDAQEEAQECAQZthR4MhUsCAQMBARAREQwBASwLAQ8CAQgaAiYCAgIlCxUQAgQBDQUbB4MAAYFqAx0BAgyiKQKBOIhgcYEygnoBAQWBNgKBD4JDGIITAwaBDCgBihuBQxeBf4E4H4IeLj6CYQEBA4E1KYMLMoImiHyDKIJZmwttCQKCGoZZiHCERxuCLYcljjqNOoExhhmQCwIEAgQFAg4BAQWBUDiBWHAVOyoBgkGCQgcFF4NOhRSFPgFygSmMCgGBIAEB
X-IronPort-AV: E=Sophos;i="5.64,308,1559520000"; d="scan'208";a="384564543"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jul 2019 21:50:52 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x6PLoqBC027002 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Jul 2019 21:50:52 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Jul 2019 16:50:52 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Jul 2019 16:50:51 -0500
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 25 Jul 2019 16:50:51 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HagiqojK6ipjjsq5muSjlOYriiPjhTNNyOA5jgtCFG/JhhdAJGOIcQbqvNvk78nrxuvn09joNuuaiRkQD/T96SGDvnQeI8WJG4fS4QQp5nplNcT3ZXzut0oE/R+tKle2/gUjqKdHkmuN+ZZ48GaK9mBKWxcP2uiYB/TxMNxJAV/fXoTzFzaqb1e5MHKFtZcrXMxDyQ/keoZDozO3DZa2SVImj26n5/o36nGaE9EYstqQ/xIU+fVneiAUmzOpAuOYtkOjFGWtbajgN/xiDu/rXf6FhkNqM8t9a0dvZRbRcmeJRvcd/89cyNQMD8CAIAinlM9EXZLZ2nYxsiFtYvFbiA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u3jkf/lWwGGLNFXqDhCDqDkMmWSHNN2BwhK95ZAnhTc=; b=AFGHimW0w5qvjzPhbSlQ8SBvwe5xlsvqagi0K0Wmt48CMFTtOgaSwlp6yWmkepuVk0pg40TtoKxP6ATNUK36FBGkV3KhSTF/HgMSZdY5+SvwDST2569ZcLmiJ+rgCINlJuDd05QsxKjz2m9Y+ppHUhyzuQNxltcJXhVX/tM2zCfletgJ9uk7ZhGkER4+vyCZ5QaVSiKfWQQUl5CnhBmroZvv7N0mZtjROsHU7XJWD8a+aog0+S8YowvHYW4i5zY+Zqn8fvztuDnOqr2esFwFTIh7mDEffmhlSRkHqOb/gyoI7z7eo5QSzl5WkiEJZkYDOlk2XTHe/+HevCjLuAhVsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u3jkf/lWwGGLNFXqDhCDqDkMmWSHNN2BwhK95ZAnhTc=; b=lN6jf0WyNLQ9c2HbB5dnlO0www0zdLYviM7XA5Ahtt68kjT1tSqAiUyYwWWNoXOD9i4+cLro7TcU9brOrc1wpEgGJcxtqP7yU76cvtVp7IY2vNyhiuU9EFyO63NYHoWJvhhkGTg2NKtInAZmCKOepJ5V+KcHaQouuHAgb+zocUo=
Received: from BYAPR11MB3703.namprd11.prod.outlook.com (20.178.237.220) by BYAPR11MB3704.namprd11.prod.outlook.com (20.178.237.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Thu, 25 Jul 2019 21:50:50 +0000
Received: from BYAPR11MB3703.namprd11.prod.outlook.com ([fe80::4ca0:1d8d:a720:2ca9]) by BYAPR11MB3703.namprd11.prod.outlook.com ([fe80::4ca0:1d8d:a720:2ca9%5]) with mapi id 15.20.2115.005; Thu, 25 Jul 2019 21:50:50 +0000
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Paul Wouters <paul@nohats.ca>, "idr@ietf.org" <idr@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [Idr] My mic comments on security
Thread-Index: AQHVQvfESlRx5osqvk6ShLu0KhsWR6bbasKA
Date: Thu, 25 Jul 2019 21:50:49 +0000
Message-ID: <0A920EB8-A7E7-4CB5-AF23-9F4A446596F0@cisco.com>
References: <alpine.LRH.2.21.1907251026480.23797@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1907251026480.23797@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1b.0.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sajassi@cisco.com;
x-originating-ip: [128.107.241.162]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 379c26e1-0d94-47f5-8554-08d7114a2889
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3704;
x-ms-traffictypediagnostic: BYAPR11MB3704:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR11MB3704BE14EE2BE67694A1DF25B0C10@BYAPR11MB3704.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0109D382B0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(346002)(396003)(136003)(39860400002)(189003)(199004)(478600001)(305945005)(966005)(15650500001)(66946007)(64756008)(66476007)(66446008)(14454004)(2501003)(7736002)(25786009)(4326008)(76116006)(71200400001)(71190400001)(14444005)(66066001)(66556008)(99286004)(446003)(11346002)(2616005)(476003)(6506007)(102836004)(76176011)(256004)(186003)(486006)(26005)(316002)(8936002)(86362001)(6486002)(229853002)(6436002)(110136005)(58126008)(33656002)(36756003)(6246003)(3846002)(6116002)(68736007)(5660300002)(2906002)(6306002)(6512007)(53936002)(81156014)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3704; H:BYAPR11MB3703.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: zREoMum3QkzTFV1C1DgFCOJxSK4foz3uQbPirNTie7HGLJg/Y+cirkCfcb3e1LhIllgA+Nuqp9ChCjOpxJKC3BsMctAGT5j+xYUzI7y3NmSgU1etry5S/4oktDKhnJU0tFjWX2en0xUvpiG6idUrCkMPP02uQqoTV8ZrdG580kgjEQ5WMOKAB8rqQSXDWBc5hlHS9TDM6jJbrwLzu0pohIzYYkJl8IHICuc4gMpEZtPTfRU2wtYp9CeBH9+UkV3aXx0sp19chAiDCz6lsOMYV/QBnteyHN2cBlBKUG3Kt92G/48OmVT7UN9sQAD/DU5ZAU4nFpKna946ojVwSudGRyzjwRqCwx1C6jAT/a94329oi+f8YXSjRGafw+xp4aIuDhV9c2JyPB2jJE75NH+aK0/CKbdmmLwYJiubqZWvQF4=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2F45D6937074E945A3DC62966FA50044@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 379c26e1-0d94-47f5-8554-08d7114a2889
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 21:50:49.9459 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sajassi@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3704
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OyYAKFVvPoS44MmcVBkcaQblaAE>
Subject: Re: [Idr] My mic comments on security
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 21:51:04 -0000

Hi Paul,

Thanks for your  comments and discussions at the mic yesterday and summarizing them below. Please refer to my reply in line marked with "Ali>"

On 7/25/19, 7:46 AM, "Idr on behalf of Paul Wouters" <idr-bounces@ietf.org on behalf of paul@nohats.ca> wrote:

    
    Note I had some questions in my previous post, that related to
    draft-hujun-idr-bgp-ipsec-00 but also applies to some of the
    other proposed solutions.
    
    At the mic I had the following questions/comments:
    
    - IPsecGW's vs Routes
    
    Depending on the amount of IPsec hosts versus the amount of routes (aka
    IPsec SA's), there are two different models that might apply better.
    
    1) A host to host IPsec connection in transport mode, using GRE or
        similar to add/remote routes without needing to update IPsec state
    2) A host to host IPsec connection un tunnel mode, which a single IPsec
        SA per route object.
    
    There are likely scenarios where either one will perform better.
    
Ali> There are use cases for both. As I was explaining yesterday, there are different level of granularity and there can very well be simultaneous IPsec SA for these different level of granularity. For example an edge box supporting 100 tenants can have a single IPsec SA for 90 of these tenants but for other 10 tenants, there can be a need for a separate IP-sec SA per tenant.

    - Optional vs Mandatory
    
    My question was whether an indication for IPsec is a commitment to
    require it or a suggestion to use it. That will cause some
    implementation differences. For example, kernel ACQUIRES can only
    be generated when the policy is mandatory - that is plaintext packets
    will be dropped until an IPsec tunnel is up.

Ali> This is a matter of local policy but I agree that a default behavior should be specified. So, the default behavior in case of IPsec should be conservative and if the tunnel is not available, then drop as opposed to send it in clear. However, if a coarser tunnel is available (e.g., in the example above, there is a IPsec tunnel per box but the tenant IPsec become unavailable), then I think the default behavior should be use the coarser tunnel temporally (for a default duration of time).
    
    - MTU issues
    
    By adding another layer of encapsulation with IPsec, the MTU is slightly
    reduced. I did not find text about this in the drafts. Should the
    administrator or implementation do something to counter the slightly
    smaller usable MTU or is it expected that each flow handles this itself
    in the normal path mtu discovery?
    
Ali> Yes, MTU size should be captured in our documents.

    - Round Trip Time
    
    One can setup a childless IKEv2 SA (two roundtrips) between hosts in
    anticipation of routes. Then the first route that would need an IPsec
    tunnel only requires one roundtrip instead of two round trips.
    
    This might not matter at the scale things happen, but often in a mesh
    of nodes doing crypto, the majority of nodes do not talk to each other
    and this work might be overkill for theoretical saving of 1 RTT upon
    route object change.

Ali> This optimization doesn't apply to BGP-based signaling and in case of IKE as you pointed out it doesn't make a dent to O(N^2) number of messages needed when full-mesh of IKE sessions needed among N nodes.
    
    - Multicast IPsec
    
    While it was supported in IKEv1 (which you should not use), work for
    this is still in progress for IKEv2. If you need this support, it would
    be good to let the authors of draft-yeung-g-ikev2 know that they have
    some new potential customers and please proceed with the work.
    https://tools.ietf.org/html/draft-yeung-g-ikev2-16

Ali>  Yes, besides IKEv2, we also need to handle multicast for IPsec SA using BGP-based signaling. 
    
    - Session resumption
    
    I'm not sure if this can be applicable but using session resumption
    instead of deleting and starting from scratch for a new IKE SA
    would save precious CPU time.
    
Ali>  We will factor that in for BGP-based signaling.

    - Tunnel inactivity
    
    Please do not start using liveness/DPD at the once per second time
    frame. There are other methods to detect tunnel inactivity, such
    as using a PFKEY/NETLINK API call that installs a soft-idle timer
    within the kernel.
    
Ali> Sure, we will factor that in as well. 

Regards,
Ali
    
    Please note I'm not on this list. If you wish to get my attention,
    feel free to CC: to messages to the idr list.
    
    Paul
    
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr