Re: [OPSEC] WGLC for draft-ietf-opsec-v6-19

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Mon, 07 October 2019 07:00 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F4B12002F for <opsec@ietfa.amsl.com>; Mon, 7 Oct 2019 00:00:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=iunIQCgm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GebB0f2n
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 I4L7dlvruJxx for <opsec@ietfa.amsl.com>; Mon, 7 Oct 2019 00:00:46 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2986D12003E for <opsec@ietf.org>; Mon, 7 Oct 2019 00:00:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29989; q=dns/txt; s=iport; t=1570431646; x=1571641246; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+cH8RBVpBdFBHdiO9SzBONa07Z+kzrlHlzvTBsatHvc=; b=iunIQCgm71P9Dant9ZbL4ZNhb4ow9YIU6+RV3aENFEgquzcAX9C4KBaI CquLqLq82KGeMHaSFk605Q6iKsOwgqpz+ZXwKiLNhVovyLjJ75KRwALbQ 5Pb+e2pZy5cZBXR7V36VkMQ+1eA46D0vRNaZcH8YLALYrMp6QHGivWzxg I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AaAgVxBPVdVDUjTptNOol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAACu4Zpd/4MNJK1jAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEMAQEBAQEBgWeBHC8kLANtViAECyqEI4NHA4pIglyJaY4TgUKBEAN?= =?us-ascii?q?UCQEBAQwBARgBCgoCAQGEQAIXgj4jOBMCAwkBAQQBAQECAQUEbYUtDIVLAQE?= =?us-ascii?q?BBAEBEAsGHQEBByIDCwENAgIBBgIOAwMBAhYSAwICAhkGBgsUCQgCBAENBSK?= =?us-ascii?q?DAAGBHU0DHQECDJAYkGECgTiIYXWBMoJ9AQEFgTgCgQ+CQQ0LghcJBYEvhRa?= =?us-ascii?q?GeBiBQD+BEAEnH4JMPoIaRwEBA4EZEgESASURCQEFBwkJCIJGMoImjHMdgl2?= =?us-ascii?q?FNZddQQqCIoYlZIUXhHGEBxuCOodOhCyJLIFfjiyIIYINjwQCBAIEBQIOAQE?= =?us-ascii?q?FgWkiRCNxcBU7KgGCQQlHEBRWeYNzhRSFP3QBCyZ3jW8PFwSCKgEB?=
X-IronPort-AV: E=Sophos;i="5.67,265,1566864000"; d="scan'208,217";a="338980902"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Oct 2019 07:00:44 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x9770i3d006878 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Oct 2019 07:00:44 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 7 Oct 2019 02:00:43 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 7 Oct 2019 02:00:43 -0500
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 7 Oct 2019 02:00:43 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AVMCICnOZ30toBUgpfHvbWA4gQ0rG2Tj/gkP7E6Xyo12dAGqnGGYy2427JsuncngvjARuPlyv6mh/u9nDsd2wUuKXzYCTcFrjUTMLRn8Yl9W05EfK+OR/iP6/ETnp8EacD26VuG2m9GY/WuqemDv+YyYEWEXEUwFyssg5nN4zTKscbdxVE7JjYhwtOiP5fy1dTAEePKcsYV4OXUc43GK9conSksE6M70s/zpqROikCqvcp9RlAnwfok+MOdOszqewlIW5PS4a7NYmIy9qK99/zqfK+jwnMXDlihjjE3B9fOFhF+T/1si+Lyo4Gn3jPXtxu/Z+jvJ4f2eNV0icdeKRQ==
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=+cH8RBVpBdFBHdiO9SzBONa07Z+kzrlHlzvTBsatHvc=; b=EsoPcBe86K8af8mCcSw9xgmS5npTmcM5GOuImvFRPcgYe+tBtoqj0yahhqMFlJuh87AiASy3znDvvQ/pPGm8MpU+Ta4DiXcnKNn97JGocXkywrW8s6xK3VdAlNXbeJThwJwom4DaZKFS27/uChawQtwGzqUKYbZBznlPoEsUOJD0kWxcGLGM4/6rAaSR6eZfWJOC75fLID65TS3qwdIgXxIX3u3yLroRyEx8XkC/AluRFJjZonaCXBuxe6cNJT8tmQ1k65u5zsvgoMiOrrDS1XQZ2HgLG6aZW8JLgYmeZXrEVMqBugA2SZW/9aOO2IAOgEZB7W4WkBqHxCP5wBX46Q==
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=+cH8RBVpBdFBHdiO9SzBONa07Z+kzrlHlzvTBsatHvc=; b=GebB0f2neadA5uEMAmelXXfIeqVpDKUAnNGDyW0bYccP1ivhYLQ4MkVfSeHTSvX3BRSCovFaESQsbxtrGKbG0MjuRV6BX2ujA8kqntsjuFak6crweHk7e4qg8EkggZUZ3u9SA0GTXoZIHDRxmq6XJI2kPJzc9CSDc2P0TGi5FXc=
Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4397.namprd11.prod.outlook.com (52.135.38.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.24; Mon, 7 Oct 2019 07:00:42 +0000
Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::e4f8:d335:c018:c62a%7]) with mapi id 15.20.2327.023; Mon, 7 Oct 2019 07:00:42 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, Jen Linkova <furry13@gmail.com>
CC: opsec WG <opsec@ietf.org>
Thread-Topic: [OPSEC] WGLC for draft-ietf-opsec-v6-19
Thread-Index: AQHVcmps0oamayy0fUCZLNWaZkv3jqc6O0UAgBS7SYA=
Date: Mon, 7 Oct 2019 07:00:42 +0000
Message-ID: <832EECB8-728D-410D-B55E-B4A9476D517E@cisco.com>
References: <CAFU7BAQCXsda0sDSUnuRJM5eR-PzmyC6NYvpgeCRVSScP+7xqQ@mail.gmail.com> <CABNhwV26o=fyOKS2eBS6HH7dw2bZqT8+mERL_c-e3kRqdvC5MA@mail.gmail.com>
In-Reply-To: <CABNhwV26o=fyOKS2eBS6HH7dw2bZqT8+mERL_c-e3kRqdvC5MA@mail.gmail.com>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com;
x-originating-ip: [2001:420:c0c1:36:7489:80bb:3f14:8c5d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4267206b-446e-4560-6702-08d74af41192
x-ms-traffictypediagnostic: MN2PR11MB4397:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MN2PR11MB4397AA70176C0C806C644E75A99B0@MN2PR11MB4397.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01834E39B7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(199004)(189003)(102836004)(53546011)(36756003)(186003)(6506007)(76176011)(6436002)(5660300002)(446003)(11346002)(46003)(99286004)(7736002)(966005)(14454004)(486006)(66574012)(606006)(6116002)(2616005)(4326008)(25786009)(476003)(2906002)(478600001)(6486002)(86362001)(256004)(14444005)(45080400002)(58126008)(54896002)(6512007)(33656002)(71200400001)(71190400001)(110136005)(6306002)(236005)(316002)(81166006)(81156014)(8936002)(6246003)(76116006)(91956017)(229853002)(66446008)(64756008)(66476007)(66946007)(66556008)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4397; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: c+MtLRU2PSjYnKliqY1VdVL6tje1hgVtTY0jkPuYQn3/BxGj8QPXJIbtyGQjEgfRhIkBnl7Yr+m4JayNSywczilzNciwxFT6TzGvoxufn37Mtz4aITCMk63Zly/rtXkUfCTKfKPxgo0B41LFPnsnwzD+5YHXp92EPNvHpeTfN29jCSkTUErzy4xUrAMDa/QG2txpw28KXP5pyyBkwfebZTkuJX1GOba7kBguKgxvRZ12xE1w9A913xXceTc8B6kxhXeAg96pFFSFgSqjDnIX2VT9wGdAah2K/qSTTP4JAHg71/pA0Tq5pQ6M8+1r7rXrBshX13m9TIZGS+GRSdNOuFMRholqheYpTyL6hLGTJALzV8CZgDKAMrKlPwQIyvVVULFlDLarIppzv+K569UTE41XJTP6nLmilsWrfVFiUEznEMypwJ2ToEes9tVSpSEE1Q+gvWR7nMVI+h/gxHgP/w==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_832EECB8728D410DB55EB4A9476D517Eciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4267206b-446e-4560-6702-08d74af41192
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2019 07:00:42.1618 (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: rZkVB2b+thWFL3RZTC80uxX/fOyMbOk0bR3FeHxVIty9z9GHVmqk+x3vwELCaud2cEnXygSFP3a9CXGwjJwdRw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4397
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/IjhRqch-w6zUWXgdg1XaGD_-5gQ>
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6-19
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2019 07:00:49 -0000

Gyan,

Thank you for reviewing our draft. It is very much appreciated by the authors.

As a co-author of this draft, I agree with your point of view on the stability of IPv6 addresses in the specific case of a  “trusted network”, esp when RFC 7127 and 8064 are widely deployed.

See more comments in line with EV>

Regards

-éric

From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tuesday, 24 September 2019 at 06:25
To: Jen Linkova <furry13@gmail.com>
Cc: opsec WG <opsec@ietf.org>rg>, "draft-ietf-opsec-v6@ietf.org" <draft-ietf-opsec-v6@ietf.org>rg>, OpSec Chairs <opsec-chairs@ietf.org>
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6-19
Resent-From: <alias-bounces@ietf.org>
Resent-To: Eric Vyncke <evyncke@cisco.com>om>, Kiran Kumar Chittimaneni <kk.chittimaneni@gmail.com>om>, Merike Kaeo <merike@doubleshotsecurity.com>om>, <erey@ernw.de>
Resent-Date: Tuesday, 24 September 2019 at 06:25

Hi Jen

Comments in-line

I just joined the OPSEC workgroup and read through some of the drafts. Right up my alley. 😃

Regards,

Gyan

On Mon, Sep 23, 2019 at 7:55 PM Jen Linkova <furry13@gmail.com<mailto:furry13@gmail.com>> wrote:
Hello,

This message starts a Working Group Last Call for draft-ietf-opsec-v6-19
(https://tools.ietf.org/html/draft-ietf-opsec-v6-19)

Please review the draft respond to this email to support the document
and/or send comments by 23:59 UTC on Fri, Oct 11th 2019.

Thanks!
--
SY, Jen Linkova aka Furry

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org<mailto:OPSEC@ietf.org>
https://www.ietf.org/mailman/listinfo/opsec


[Gyan]  In  section 2.1.5 below  on corporate intranets where you are on a "trusted" network where the hosts are "trusted" the use or need for privacy extensions are not necessary and accountability by far outweighs the privacy extension to maintain anonymity from an IT security.  I have deployed within Verizon's internal network as well as other customers a standard of disabling privacy extensions random station id as well as temporary address so that all hosts are accountable and traceable and the addresses remain stable with EUI64 address or dhcpv6 address.  With RFC 8064  & RFC 7217 are adopted by windows & other desktop OS's and become the default we can revert our IPv6 deployment standards back to the OS defaults.  Section 2.1.4 talks about scanning and static IPv6 addresses however should also take into account enterprises where hosts are "trusted" and that scanning is a requirement for enterprises having a historical database dump of arp cache & nd cache of all hosts addresses both IPv4 & IPv6.

 2.1.5. Temporary Addresses - Privacy Extensions for SLAAC -

In some extreme use cases where user accountability is more important than user privacy, network operators may consider to disable SLAAC and rely only on DHCPv6; but, not all operating systems support DHCPv6 so some hosts will not get any IPv6 connectivity. Disabling SLAAC and privacy extensions addresses can be done for most OS and for non-hacker users by sending RA messages with a hint to get addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting all A-bits in all prefix information options. However attackers could still find ways to bypass this mechanism if not enforced at the switch/ router level. However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used.

Can we add a  section related to IPv6 inherent capability of the host to maintain many IPv6 addresses and security concerns as to which IPv6 address is used for conversation flows and the host OS default address selection rfc 6724 internal mechanism used to determine which IPv6 address is used for conversations.  With SLAAC its possible to have a router with many addresses configured and all hosts on the subnet in that hypothetical scenario would get an RA advertisement with no limits as many ipv6 addresses that are configured on the router.

EV> This issue  (multiple addresses per host) is described in section 2.6.2.3  and at the end of the introduction of section 2.1 ? Unsure whether the document should go further but the next rev will have some more text in section 2.1.

In section 2.1.2 Point-to-Point links you mention a use case of infrastructure routed p2p links only require being configured with link local via Cisco "ipv6 enable" for ipv6 packet processing and I believe Juniper & Huawei have a similar command so that the IGP OSPF or ISIS adjacency can form via LL LSA updates however the major security and operational downside is that the traceroute is unable to show the in/out hop by hop routed interface IPv6 addresses along the path to be able to perform a hop by hop ping/trace when troubleshooting network issues related to latency, jitter or drops.  So from a security standpoint it is recommended although not required to place IPv6 address on all P2P routed interfaces.

EV> Indeed OSPFv3 & RIPng only use IPv6 LLA to form adjacencies (IS-IS does not have IP address) and I can only agree with the above as the co-author of RFC 7404 ;-)

From an addressing perspective and also for security standpoint the ability  to craft an ACL allocating all infrastructure /128 loops from a single /64 and /127 form a single /64 is recommended and coming out of the same higher order block bit boundary such as a /56.  In implementations that I have deployed we used as a standard addressing schema  "0  /56" -  0 /64 Loops, 1 /64 P2P and then instead of going crazy with vlsm we would have a single mask we made it a /120 similar to /24 for IPv4 that covers greater then 2 host nets router infra like router backbone ring or firewall subnet and then last a /64 for all host subnets so simple addressing allowing ability to craft security ACLs as necessary for all infrastructure subnets /128-loops /127-p2p /120- >2 host subnet.

EV> Thank you for the return of experience

-éric


Regards,

Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT<http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>