Re: [Idr] Securing BGP sessions (Issue#41)

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 13 December 2019 23:09 UTC

Return-Path: <mjethanandani@gmail.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 B0917120863 for <idr@ietfa.amsl.com>; Fri, 13 Dec 2019 15:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6qVyDIP6FdRe for <idr@ietfa.amsl.com>; Fri, 13 Dec 2019 15:09:35 -0800 (PST)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78712120849 for <idr@ietf.org>; Fri, 13 Dec 2019 15:09:35 -0800 (PST)
Received: by mail-pj1-x102f.google.com with SMTP id w5so340961pjh.11 for <idr@ietf.org>; Fri, 13 Dec 2019 15:09:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5FBkhjxevSvQx/Z3UJOo4cPPRRSbfCG7RGPMxEaQ/zQ=; b=JS+Wd3f3Xv7rMa64e9OqnaYKS2ptCp1dqLkcSVxJKNL/77W50gNEpkxsVDNpnPcTF8 cQyxG5ZNSBcvKLcsUfGtBR3sr0cwXGMYnuiP2q/DMfqq1GLgO44OilkXrQf0ipoBAiET ZQIqHLcj5hmg9++8l0ZBG/iHYB47/hWyJ+na6biWdnHXUdZVSLowaM/5K5U5cmohZux5 NmsfEqLuk3nY7NjXoN7LjPyFj1CX8WXm9xPODtphfhBuREunm861/pVA+7sY5roONJwx cXxjlYcs+zq/KVfswaAgrvZd1MBrPsQSQoxs/zzpAHy49P3RBlmGLt+rY+/Wq5xn15K/ mx1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5FBkhjxevSvQx/Z3UJOo4cPPRRSbfCG7RGPMxEaQ/zQ=; b=VbRRz/zcjnm9F7jJam0i0Wd+pBiF9ozTbX+rVCAG48lGYlAF08T8Wz/iXIMQoBEpBR 2pRrTchmjrQqtprLn0wSMz6edas0UvoWKkNeI0b9nUFZFY+BJJTWFMkgbQuwKw60kiUR 6ue+cAoomcUl3wjj9X0aTMQRzfjFMZa1jiiIQ8jAZtgzvS+vax8Ts/2H/4E/NVZiBo/O sq2778bvOcOsRuLX/BxJikdSjtufBF+ggjoeMx5sVHLLA6OrhcEsNP3P3YZ79AIy8YYA dYc7O38cNtvlXrziKCJ+HIuuQ+BSGA/BFP26HmPpYe3kfe2ZI3DZn0u9/WvhqOo+r9+i uatw==
X-Gm-Message-State: APjAAAU+8wxXobGify41NAF21XmuTV2DAe71oGLJJahoxA1wrygLqBx7 6MO+Kz3Uijs9k6hE1RUcVrA=
X-Google-Smtp-Source: APXvYqwvFq/DKuqFrZOzejYAX38epIuqbq1fGZTUAhR9s44ytSLz5bsvZ2SXeyLWvqh3smw3VQVc4Q==
X-Received: by 2002:a17:902:8608:: with SMTP id f8mr2137200plo.106.1576278574713; Fri, 13 Dec 2019 15:09:34 -0800 (PST)
Received: from ?IPv6:2601:647:5600:5020:85b0:636a:fdd9:8b35? ([2601:647:5600:5020:85b0:636a:fdd9:8b35]) by smtp.gmail.com with ESMTPSA id b2sm13338552pff.6.2019.12.13.15.09.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Dec 2019 15:09:34 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <D8A5A1E6-2978-4720-9441-C894608F6F35@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D71AFA81-297C-4CBB-BC06-BD5F3DA539E4"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 13 Dec 2019 15:09:32 -0800
In-Reply-To: <DE40EA38-504C-4D6F-B697-DD3325577C05@cisco.com>
Cc: "idr@ietf.org" <idr@ietf.org>
To: "Acee Lindem (acee)" <acee@cisco.com>
References: <D9C310C0-89C6-4CB5-80A2-98C274581E7F@gmail.com> <68B00DBF-3590-4ECE-8028-301643B9E49E@cisco.com> <91B63CF9-B92B-4D14-98CA-EBC865999B08@gmail.com> <A8395DB8-6D10-46A1-99A1-DFFB9B2CBD9D@cisco.com> <E126FB83-AB0B-46C6-91F0-396C9C4FBE9E@gmail.com> <DE40EA38-504C-4D6F-B697-DD3325577C05@cisco.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cezb0SIm6vPGFlwvw-EQ626BTXs>
Subject: Re: [Idr] Securing BGP sessions (Issue#41)
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: Fri, 13 Dec 2019 23:09:38 -0000

Hi Acee,

> On Dec 13, 2019, at 10:47 AM, Acee Lindem (acee) <acee@cisco.com> wrote:
>> 
>> 
>> Well it doesn't help at all.... Normally, the usage of IPsec (AH, ESP, algorithms, key exchange, etc.) would be specified in some document. For example, IPsec usage by OSPFv3 is specified in RFC 4552. Granted, it is a lot simpler for BGP than OSPFv3 since BGP is strictly P2P but specification would still seem to necessary. 
> 
>    You are right. It should be some document. That document in my mind is the YANG model for IPsec/IKE, something we need to ask the SEC ADs about. You would agree that what needs to be defined is not BGP specific, and therefore does not belong in the BGP model.
> 
>    Much like TCP-AO and TCP-MD5 I expect this other document to define a grouping that the BGP model imports and uses to define what is needed to setup IPsec.
> 
> Actually I disagree with you - TCP MD5 and TCP-AO are more than adequately documented. 
> 
>   MD5 - https://datatracker.ietf.org/doc/rfc2385/ <https://datatracker.ietf.org/doc/rfc2385/>
>   TCP-AO - https://datatracker.ietf.org/doc/rfc5925/ <https://datatracker.ietf.org/doc/rfc5925/>

What you are pointing to me is the document that describes how the two technologies can be used to secure BGP. I am aware of those RFCs. The document I am looking for is a YANG model that defines a grouping for MD5 and TCP-AO that the BGP model can import and use. 

> 
> It is only IPsec transport mode that isn't described. Also, I don't know of anyone who supports this so I'm wondering why it is in the discussion for this version of the BGP YANG model.

I will let Jeff comment on this.

Cheers.

> 
> Thanks,
> Acee
> 
> 
>    Cheers.
> 
>> 
>> Thanks,
>> Acee
>> 
>> 
>>> For IPsec protection of BGP, where are the details specified? 
>>> Thanks,
>>> Acee
>>> 
>>> On 12/10/19, 7:35 PM, "Idr on behalf of Mahesh Jethanandani" <idr-bounces@ietf.org on behalf of mjethanandani@gmail.com> wrote:
>>> 
>>>  This is the second thread in the list of issues that were discussed in IETF 106 w.r.t. to BGP YANG model. This particular thread is to discuss the issue of defining how BGP sessions are going to be secured.
>>> 
>>>  As stated in Singapore, the model is being defined to secure BGP sessions using 
>>>  - TCP AO
>>>  - TCP MD5
>>>  - IPSec
>>> 
>>>  In case there was a question of why MD5, it is because there are existing implementations that are choosing to stay with MD5, regardless of the issues that have been raised about MD5. The model therefore has to support such implementations.
>>> 
>>>  The model will use the ietf-key-chain model’s (RFC 8177) key-chain-ref to refer to an instance of the key chain. By doing that it will make use of the key rollover capability defined in that model, and for static key configuration by setting the end time to infinite in the key chain. The BGP model will leave the case of IPSec as TBD for now, and fill it when/if the IPSec YANG model is defined.
>>> 
>>>  Questions/Concerns?
>>> 
>>>  Mahesh Jethanandani
>>>  mjethanandani@gmail.com
>>> 
>>> 
>>> 
>>>  _______________________________________________
>>>  Idr mailing list
>>>  Idr@ietf.org
>>>  https://www.ietf.org/mailman/listinfo/idr
>>> 
>>> 
>> 
>>   Mahesh Jethanandani
>>   mjethanandani@gmail.com
>> 
>> 
>> 
>> 
>> 
> 
>    Mahesh Jethanandani
>    mjethanandani@gmail.com