Re: [Idr] BGP Yang - support for ipsec for BGP sessions?

Susan Hares <shares@ndzh.com> Sat, 08 January 2022 20:42 UTC

Return-Path: <shares@ndzh.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 A5F5D3A0C3A for <idr@ietfa.amsl.com>; Sat, 8 Jan 2022 12:42:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.359
X-Spam-Level: *
X-Spam-Status: No, score=1.359 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 IvYxo5ELfFUW for <idr@ietfa.amsl.com>; Sat, 8 Jan 2022 12:42:28 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E1E3E3A0C0B for <idr@ietf.org>; Sat, 8 Jan 2022 12:42:27 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.89.79;
From: Susan Hares <shares@ndzh.com>
To: 'Gyan Mishra' <hayabusagsm@gmail.com>, "'Acee Lindem (acee)'" <acee@cisco.com>, 'Jeffrey Haas' <jhaas@pfrc.org>
Cc: "'idr@ietf. org'" <idr@ietf.org>
References: <2E52B35E-6A0B-442B-9F83-31430B2CF112@pfrc.org> <CABNhwV1zHPE_8DcyNAfUvO3bOGMrUMQ42Y=E-FeyBBpp=FnNyw@mail.gmail.com> <A0A1B099-D4E3-4ECB-B32F-12C3051E1131@cisco.com> <CABNhwV2TjPqvvPwJ4Ls-NMeErMCL2aR8NnGmWaCTiSaR-me2SA@mail.gmail.com>
In-Reply-To: <CABNhwV2TjPqvvPwJ4Ls-NMeErMCL2aR8NnGmWaCTiSaR-me2SA@mail.gmail.com>
Date: Sat, 08 Jan 2022 15:42:16 -0500
Message-ID: <021c01d804d0$3c64fe70$b52efb50$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_021D_01D804A6.53911950"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEQ8tgsWGJPDtX1Pf4QhXQ/GS4dOwEBPpIyAeKn2SwCJ2CH7K2/YHVg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MfNJcxvNGNJYEXOqNbQL63cVuJk>
Subject: Re: [Idr] BGP Yang - support for ipsec for BGP sessions?
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: Sat, 08 Jan 2022 20:42:36 -0000

Based on Jeff, Gyan and Acee’s comments – I have few wider questions. 

 

If IPSEC is used to provide secure transport/tunnel (MD5 authentication + secure IP + encryption)  specific to a peer,  it seems to point to a BGP peer configuration for the transport/tunnel.  Based on Juniper + Gyan’s comment, this BGP peer configuration process could link to IPSEC security yang structure  

  

If IPSEC is automatically sets up a tunnel on an interface, this seems to point to an security function definition (ietf-i2nsf-ike module) definitions.  This seems to me to be outside the BGP realm based on the interface used.   The sanity of the authentication, encryption, hashing, and management depends on tunnels. 

 

If the BGP tunnels (RFC9012 + extensions) are configuring  IPSEC connection structures for tunnels, where does this configuration lie?  Is this structure a BGP main module structure, a RFC9012 Yang module, or something else?  

 

What prevents these 3 options from conflicting in implementations?

 

These are not the only three cases.  The BESS Draft  <https://datatracker.ietf.org/doc/draft-sajassi-bess-secure-evpn/> aft-sajassi-bess-secure-evpn-05.txt suggest a different combination of this for EVPN.   

 

It would be good to know how these interact in today’s implementations.   

 

Sue 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Gyan Mishra
Sent: Tuesday, December 28, 2021 7:38 PM
To: Acee Lindem (acee)
Cc: idr@ietf. org
Subject: Re: [Idr] BGP Yang - support for ipsec for BGP sessions?

 

 

 

On Tue, Dec 28, 2021 at 7:21 PM Acee Lindem (acee) <acee@cisco.com> wrote:

 

 

From: Idr <idr-bounces@ietf.org> on behalf of Gyan Mishra <hayabusagsm@gmail.com>
Date: Tuesday, December 28, 2021 at 7:05 PM
To: Jeff Haas <jhaas@pfrc.org>
Cc: IDR List <idr@ietf.org>
Subject: Re: [Idr] BGP Yang - support for ipsec for BGP sessions?

 

Hi Jeff

 

SA is a security association between the IPSEC Net to Net VPN router tunnel endpoints that defines encryption algorithm and AH and/or ESP and key exchange.  

 

I think Junipers implementation the way I read is a Net to Net VPN between two routers and routing protocol BGP is included in the IPSEC ACL defining the interesting traffic transport tunnel mode.  That is what the direct association to peering sessions essentially putting the peers inside the tunnel instead of outside the tunnel.

 

Transport mode and tunnel mode are two separate encapsulations. There is no tunnel for the former. AFAIK, “traffic transport tunnel mode” doesn’t exist as a standard. 

 

See https://www.rfc-editor.org/rfc/rfc4301.html#section-3.3

 

As an example of transport mode IPsec, see https://datatracker.ietf.org/doc/rfc4552/

 Gyan> Understood.  I was referring to IPSEC tunnel itself not a physical tunnel VTI in tunnel mode,  which still has the two router endpoints based on the encryption domain whether it’s tunnel or transport mode is irrelevant.  

Thanks,

Acee

 

Cisco XE can perform the exact same permitting BGP in the IPSEC ACL for Net to Net VPN so BGP session is encrypted within the transport tunnel.  So the BGP session is inside the tunnel and not outside the tunnel.

 

I don’t think IPSEC for BGP should be included in the BGP Yang mode as we are not encrypting the peer itself as we need a Security Zone  which is part of the IPSEC framework not BGP.  

 

If a vendor had a knob that could encrypt the TCP session similar to per peer level password authentication then I agree that it should be included.

 

IPv6 unlike IPv4 has IPSEC security mandated in the IPv6 specification via AH and ESP  Extension Headers but is not automatically implemented and requires IKE configuration.

 

So for IPv6 as well I don’t believe any vendor supports BGP IPSEC peering.

 

Kind Regards 

 

Gyan

 

On Tue, Dec 28, 2021 at 10:47 AM Jeffrey Haas <jhaas@pfrc.org> wrote:

[Reference: https://github.com/mjethanandani/ietf-bgp-yang/issues/59]

 

The underlying modeling question here was originally, "what does the sa name mean".  But the real question here is perhaps, "What implementations of BGP support ipsec for BGP sessions?"

 

Juniper's implementation supports as part of BGP configuration direct association for transport mode ipsec for individual peering sessions.  Of course, even without such configuration, if ipsec is used to protect connectivity between the endpoints in tunnel mode, BGP just uses that automatically.

 

Does anyone else's implementation have similar functionality?  If so, please provide a pointer to your configuration so we can decide what to do with the IETF model for this option.

 

Thanks,

 

- Jeff with his BGP YANG author hat on...

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

-- 

 <http://www.verizon.com/> Error! Filename not specified.

Gyan Mishra

Network Solutions Architect 

Email gyan.s.mishra@verizon.com

M 301 502-1347

 

-- 

 <http://www.verizon.com/> 

Gyan Mishra

Network Solutions Architect 

Email gyan.s.mishra@verizon.com

M 301 502-1347