[Sidrops] IETF 104 SIDROPS Meeting Minutes

Keyur Patel <keyur@arrcus.com> Mon, 13 May 2019 17:54 UTC

Return-Path: <keyur@arrcus.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9881200B5 for <sidrops@ietfa.amsl.com>; Mon, 13 May 2019 10:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.onmicrosoft.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 QPE0-UEK2i_F for <sidrops@ietfa.amsl.com>; Mon, 13 May 2019 10:54:43 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700070.outbound.protection.outlook.com [40.107.70.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBDC120021 for <sidrops@ietf.org>; Mon, 13 May 2019 10:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KqByb3WRc1e0QyML0quEu1WrKpImnckL6SN+JyUGz1w=; b=JWcnREVkA5NvyZt6j1VBsGOLvD5vkxng4fwVVlfs9CGvAyDq84rlbwCi/zywwLpWWWCNG81Q091Ne3gMSjV8CARThGKQkN8jfPt6ate1fR2pQnzTEAKimBatfCDStw7B1yhuyj4xwHwbLD9hxG40y/IAa59bIquIofibjBvOc3Y=
Received: from BYAPR18MB2856.namprd18.prod.outlook.com (20.179.58.82) by BYAPR18MB2968.namprd18.prod.outlook.com (20.179.59.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.20; Mon, 13 May 2019 17:54:38 +0000
Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::f855:74f:9e5f:d010]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::f855:74f:9e5f:d010%6]) with mapi id 15.20.1878.024; Mon, 13 May 2019 17:54:38 +0000
From: Keyur Patel <keyur@arrcus.com>
To: "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: IETF 104 SIDROPS Meeting Minutes
Thread-Index: AQHVCbTuFwhpf/S030iDc/RJPyWqXA==
Date: Mon, 13 May 2019 17:54:38 +0000
Message-ID: <29A62D35-94A6-4764-B76E-27914F5BA7EA@arrcus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com;
x-originating-ip: [70.234.233.188]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f37a66b4-7103-4321-c429-08d6d7cc118e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR18MB2968;
x-ms-traffictypediagnostic: BYAPR18MB2968:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR18MB2968DBF44669AB8354C4A010C10F0@BYAPR18MB2968.namprd18.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(346002)(376002)(39830400003)(199004)(189003)(6436002)(14444005)(2351001)(7736002)(71200400001)(71190400001)(83716004)(5024004)(2906002)(66066001)(6306002)(102836004)(68736007)(54896002)(3846002)(508600001)(6116002)(256004)(1730700003)(81156014)(8676002)(5640700003)(6512007)(6506007)(81166006)(486006)(476003)(8936002)(6486002)(86362001)(14454004)(66574012)(25786009)(186003)(36756003)(99286004)(5660300002)(73956011)(26005)(33656002)(53936002)(2501003)(6916009)(66946007)(66556008)(82746002)(66476007)(2616005)(64756008)(66446008)(316002)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2968; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 2vAsS/bZBiNFxrnH39mVmWurqD+OHSHyDHVbxGOQ8+3Jl144I5JJDgsdZSKOyGZdvvKrIHc86y/67MDfNPVQBvR0BoVeVUizG/Uqx7HKAIlElbS0hSSkhZoRr3jyGVwl2+vj9ZPPNTtg4PYj05/w/jqUdkG3/tZ/JiMWEWktALN8+kh4FQ/kCL+keJ45f6StXUCNJGH68455ERvNCmO/IhST/4v3F0+ZqgKN7RbM8C3rtqmlvxprymYBG38VXZcg49/Dle0ir6BhzKUqnWgHUErpdTV+h0I0fw/tjr3b3vhMlQZa25/B8SAnqOOCuC18QE3FDLqsC8bgF0IXpnYzBPgd31Q2BsUHzer22Yrp5sl6SRSKiGb1BBvyPWBWR9e+nYamqPii7oorKduBDKzBrLqaqB6LtVeeZnGepOSHo9w=
Content-Type: multipart/alternative; boundary="_000_29A62D3594A64764B76E27914F5BA7EAarrcuscom_"
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f37a66b4-7103-4321-c429-08d6d7cc118e
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2019 17:54:38.5614 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2968
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/VOhVqy3o0jEPyfgvR2wbuGiAyYY>
Subject: [Sidrops] IETF 104 SIDROPS Meeting Minutes
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 17:54:47 -0000

Folks,

Attached are the meeting minutes for the SIDROPS meeting at IETF 104 in Prague.
Apologies for the delay in sending out the meeting minutes.

Best Regards,
Keyur

 Meeting Minutes from Prague IETF-104


-1) Randy Bush -- draft-ymbk-sidrops-ov-signal-02.txt

-In band marking with extended community:
Sriram K. (Nist): Evaluator does validation or router does the validation?
Randy Bush: Evaluator only.
Sriram K.: Evaluator lost its rpki connection.. how does it signal router?
Randy Bush: Draft does not cover it.
Sriram K.: Should we cover the use case in the draft?
Randy Bush: Maybe.


2) Daniel Kopp -- draft-ietf-sidrops-route-server-rpki-light-02.txt

- In domain of IXP network where ROA validation results is forwarded from RS to its peers.
- Introduce a transitive four-octet AS specific Extended Community.
Jakob Heiz: Three validation states are defined and there should be the fourth state (Validation not done).
Daniel Kopp: It is missing in the draft.
Ruediger Volk: Why not have your customers do it? Extended community was chosen because large communities was missing. Asking for routers to implement it and implementation cycles are long before it goes in production. Suggest using large community?
Daniel Kopp: Happy to adopt Large community.
Randy Bush: Agree with Ruediger Volk. Suggest using Large community and same community definition.
Doug M: IXP could offer this as service?
Daniel Kopp: Yes.
Dough M: makes sense.
Job Sniders: What is lacking in the draft is secure by default approach. Suggest abandoning the draft. Should not be propagating validation state on Ebgp.
Daniel Kopp: Do not agree.
Job Sniders: Should not propagate invalids. This makes it insecure.
Randy Bush: Trade-off is whether you act for IXP member or you give IXP member more information. Question from IXP members pov is are you outsourcing your security.
Doug M: Do not agree with outsourcing security.
Alexander Azimov: You do have filtering. Why don't you use marking and why ask for flexibility? Whats the difference?
Daniel Kopp: Would like to standardize using a community for everyone.
Rudigher Volk: Consider signaling for guys who sent you invalid stuff?
Keyur Patel: Any flavor or solution deployed today?
Daniel Kopp: Dropping for default. Tagging is not done.


3) Ruediger Volk -- draft-ymbk-sidrops-ov-egress-00.txt

Randy Bush: Whatever RFC origin clarifications became is inconvenient? We do have SNMP MIBs for dropped announcements?
Ruediger Volk: Not interested in SNMP stats.
Randy Bush: Tagging announcements with different origin-as to different peers?
Ruediger Volk: It would fall under weird policy primitives.
Randy Bush: My point is the hack you want is to put a check at the end of export policy so I don't have to duplicate it.
Ruediger Volk: We are in agreement.
John Scudder: Since your telling implementors how to implement a standard make it standards based.
Andrew Dray: Please ask the implementors to show what is exactly being dropped. Another comment I have to enable policies per peer.
Randy Bush: "do NOT do ROAs for routes NOT meant for DFZ" is for AS0 peers only.
Ruediger Volk: You seem to think AS0 is special.
Randy Bush: Lets differentiate AS0 in path versus ROA.
Ruediger Volk: Agree.
John Scudder: The slide is completely unrelated to the presentation.
Ruediger Volk: Yes.
John Scudder: Last slide is interesting and thought provoking.
Job Sniders: There may be explanations as to why you are seeing unwanted ASes, Customers make ROAs with private ASes as tags, typos, etc.
Ruediger: Only when someone presents then and only then it gets fixed.
Jeff Huston: If you really wanted to understand validity of ROA why don't you sign with AS.
Ruediger Volk: Are you suggesting we mimic where Address and AS must be signed. What I suggest is simple and straightforward.
Doug M. Why is this stuff appearing in global RPKI. Is this ignorance?
Ruediger Volk: Typos, folks not adhering to guidelines and folks not knowing what they are doing.
Doug M. concerned that one off validators might clean this up but the problems may not be solved?
Rudeger Volk: Suggest a BCP.

4) Sriram K. – RPKI/ROV data analysis with detail characterization of Invalid routes

Andrey R.: How does it work? What is the query mechanism?
Sriram: We can give you a global view or a view per AS. Don't think it is ready but can facilitate that.

5) George Michelson – RPKI Validation Reconsidered

Rob Austein: Don't agree with the check at every level.
Di Ma: We don’t use OID but we use algorithm. We can switch to new validation.
Geroge M. Cool.

6) George Michelson – Resource Tag Attestation

Job Sniders: Would like to see this move forward.

7) Oliver Borchert – draft-borchert-bgpsec-validation-signaling-00.txt

Presented BGPSec Validation State Signaling.