Re: [Rift] RIFT security review

Antoni Przygienda <prz@juniper.net> Wed, 24 April 2019 01:32 UTC

Return-Path: <prz@juniper.net>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4373E120172 for <rift@ietfa.amsl.com>; Tue, 23 Apr 2019 18:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.337
X-Spam-Level:
X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 JAJh246Rp4lJ for <rift@ietfa.amsl.com>; Tue, 23 Apr 2019 18:32:19 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBB5120156 for <rift@ietf.org>; Tue, 23 Apr 2019 18:32:19 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3O1TRqX005958; Tue, 23 Apr 2019 18:32:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=H2SHLHEUSBne259HGQ3+N5e1bXBLazygTJf55U3o69Y=; b=mV6IcRLjFzVag1Eepn8JB8+RRVOCkIJRjxi7cc0rPXbumrtS+Q1fkn7283TAmd5hGutA zT8+Vl2SFIv387fJbCeKK12iFD8gfNwXPFKeQFjSO5Y1yAmvFssSWSTXDZe1fSH93HgS iMFxv3TiEnNeSLuIwQX0QmJGjSUXxiQXUs7oklZodXgu70NM4R8zIlqsj1rihCavi4NJ 45Y0rhyyieDkww6Mqj/2uEJxrLRbRheqcr1LgDA1TGSkiOzb5FHqTQyPgGIuUFLhyQQE reVjsPGld8iw4KzmhfADb1tqnvucT1HXated56r/0YvGh2wVeFJtP9Hs++Rrqe2n9XI0 ZA==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp2053.outbound.protection.outlook.com [104.47.40.53]) by mx0b-00273201.pphosted.com with ESMTP id 2s29asgc5b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Apr 2019 18:32:15 -0700
Received: from MWHPR05MB3279.namprd05.prod.outlook.com (10.173.230.18) by MWHPR05MB3197.namprd05.prod.outlook.com (10.173.229.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.7; Wed, 24 Apr 2019 01:32:13 +0000
Received: from MWHPR05MB3279.namprd05.prod.outlook.com ([fe80::c104:c5bd:b877:2202]) by MWHPR05MB3279.namprd05.prod.outlook.com ([fe80::c104:c5bd:b877:2202%10]) with mapi id 15.20.1835.010; Wed, 24 Apr 2019 01:32:13 +0000
From: Antoni Przygienda <prz@juniper.net>
To: "Scott G. Kelly" <scott@hyperthought.com>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
CC: Bruno Rijsman <brunorijsman@gmail.com>, "rift@ietf.org" <rift@ietf.org>
Thread-Topic: RIFT security review
Thread-Index: AQHU+jVaXs0vLJXv+EuMv17QAGUsTaZKhUum
Date: Wed, 24 Apr 2019 01:32:12 +0000
Message-ID: <MWHPR05MB32795F5B83AD6EE610BDCF57AC3C0@MWHPR05MB3279.namprd05.prod.outlook.com>
References: <SN2PR05MB2463D1833A557E99671C8A57D4230@SN2PR05MB2463.namprd05.prod.outlook. com>,<1556066007.970621387@apps.rackspace.com>
In-Reply-To: <1556066007.970621387@apps.rackspace.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.239.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 76dd14a0-3dbe-444f-57a9-08d6c854ad54
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MWHPR05MB3197;
x-ms-traffictypediagnostic: MWHPR05MB3197:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <MWHPR05MB3197DAF8AF17956E67D1CC4AAC3C0@MWHPR05MB3197.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3173;
x-forefront-prvs: 00179089FD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(396003)(39860400002)(346002)(51444003)(189003)(199004)(6506007)(4326008)(5660300002)(15650500001)(14454004)(9686003)(33656002)(55016002)(53936002)(966005)(8936002)(54896002)(236005)(478600001)(81156014)(6306002)(7696005)(6436002)(476003)(76176011)(229853002)(8676002)(446003)(74316002)(53546011)(81166006)(6246003)(99286004)(110136005)(54906003)(97736004)(66574012)(105004)(66476007)(256004)(14444005)(6116002)(25786009)(64756008)(68736007)(73956011)(66946007)(66446008)(66556008)(316002)(30864003)(3846002)(186003)(71190400001)(76116006)(71200400001)(19627405001)(26005)(6636002)(486006)(66066001)(1941001)(2906002)(52536014)(102836004)(7116003)(606006)(7736002)(11346002)(3480700005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3197; H:MWHPR05MB3279.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nmF9yoCmUJI+vjdq3f9ORBVlyhjyZt72Rsp5UXqGT8l48peiIduOJTj1r7HR4YQ5FTXRquy3GqcCG2CQJKf3XqVMwP/Jnqknk1I/IrtsiIRKLC3NbtZQxg35BcdPrtyIv0xGAlsriUalWYtYbcBofiZ4/DpD+DObXsZk2BSCO/xmHujUtWacxgAG4EPEP+nj52tPB1jCI7iqh0iRukYt4InuWE0VaDUyQd4XGU7g1hDQqIZpP7SBr+WYXooX8sq9dPzr0ziZWounf4PJhKdtQ+Vb6V6Q4cXUapTNuRQJuW5/DkKRnkjcHyYko2/KSeWImNzvcvIkdEecxFYUaS9P9k+vsn4uUDuR1p1B3ieyqc5J0uger63E9HGcqIbIT2ajRYszjfyWkQWqnH5vgGO3PqFFR4d2emImbTjC2Kcl2z0=
Content-Type: multipart/alternative; boundary="_000_MWHPR05MB32795F5B83AD6EE610BDCF57AC3C0MWHPR05MB3279namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 76dd14a0-3dbe-444f-57a9-08d6c854ad54
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 01:32:12.8866 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3197
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-24_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904240010
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/xF9Aa4drVP3PmUlt2vpE7iDk8Qg>
Subject: Re: [Rift] RIFT security review
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2019 01:32:22 -0000

thanks Scott, I think I added in the document some text saying "that's not _really_ a nonce but close" and that it's really combination of local & remote that is used as salt so it's 32 bits (so replay is staticially only likely for the duration of 5min/2 and only after 1^32/2 sequences have been recorded). If you think the text is not sufficient, we can rename it to "pseudo-nonce" or something like this

I probably misunderstood your comment to an extent ...

I hope that my reasoning as to "performance" in the sense of having a "real" nonce and to cryptographically fingerprint _every_ LIE on evey interface every time and every TIE on transmission/retransmission represening a very high load was clear ...

And even if we insist on "perfect nonces" then we have allow for a "nonce slip" since LIEs may get lost and so on so the protocol must allow +/- 5 nonces local/neighbor anyway to work under lossy links. So there is a a certain replay vector that is unavoidable I think ...

thanks

--- tony

________________________________
From: Scott G. Kelly <scott@hyperthought.com>
Sent: Tuesday, April 23, 2019 5:33 PM
To: Jeffrey (Zhaohui) Zhang
Cc: Antoni Przygienda; Bruno Rijsman; rift@ietf.org
Subject: Re: RIFT security review

Hi Jeffrey,

I haven't yet reviewed the document, but based on your reply, I think that all of my comments are addressed except for one. From Antonio's reply below:

>
> I was under the impression that nonce is a well-known term in cryptography
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Cryptographic-5Fnonce&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=at8GTl8R0Z06MPVIsuXx0_C74NJeGZ1xePUdjnYACtg&e=
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__upload.wikimedia.org_wikipedia_commons_thumb_4_4f_Nonce-2Dcnonce-2Duml.svg_1200px-2DNonce-2Dcnonce-2Duml.svg.png&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=sxN_f34c3v2_yMpEZgquYcJbHLXu8PmtP6nDuaIkmlc&e=]<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Cryptographic-5Fnonce&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=at8GTl8R0Z06MPVIsuXx0_C74NJeGZ1xePUdjnYACtg&e=>


This is exactly my point: read the definition given for cryptographic nonce: "In cryptography, a nonce is an arbitrary number that can be used just once in a cryptographic communication"

The key here is "just once". Because you expect rollover, and because you allow one side to hold this constant up to 5 minutes (and repeat it in any messages flowing during that interval) the same value can be used more than once. So, it does not meet the commonly understood definition of nonce (and it does not have the security properties commonly expected of a nonce).

--Scott


On Tuesday, April 23, 2019 10:30am, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> said:

> Hi Scott,
>
> Thanks for your security review on RIFT spec. I am copying this to the RIFT
> mailing list.
>
> Please see Tony's response in the email below and the revisions in
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Drift-2Drift-2D05.txt&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=W2GfTd20tkv2UsNNsAQ5w7JfplP2RJNK1o4Qb-NphAg&e=. Could you review again to
> make sure all your comments/concerns have been addressed?
>
> Thanks!
> Jeffrey
>
>
>
> Juniper Internal
> From: Antoni Przygienda <prz@juniper.net>
> Sent: Thursday, April 18, 2019 12:34 PM
> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; rift-chairs@ietf.org; Bruno
> Rijsman <brunorijsman@gmail.com>
> Subject: Re: RIFT security review
>
> My comments on the security review:
>
>
> I have reviewed this document as part of the security directorate's ongoing effort
> to review all IETF documents being processed by the IESG.  These comments were
> written primarily for the benefit of the security area directors.  Document
> editors and WG chairs should treat these comments just like any other last call
> comments.
>
>
>
> The summary of the review is ready with issues
>
>
>
> From the abstract, this document outlines a specialized, dynamic routing protocol
> for Clos and fat-tree network topologies.
>
>
>
> (should that read CLOS?)
>
> Clos was a French mathematician in Bell Labs who invented the stuff so it's really
> "Clos"
>
> Wikipedia: "Clos networks are named after Bell Labs researcher
>
> Charles Clos, who proposed the model in 1952 as a way to overcome the
>
> performance- and cost-related challenges of electromechanical switches then used
> in telephone networks."
>
>  Following is a brief summary of comments and questions by section.
>
>
>
> 5.4.1 includes this sentence:
>
>
>
>    The most security conscious operators will want to have full control
>
>    over which port on which router/switch is connected to the respective
>
>    port on the "other side", which we will call the "port-association
>
>    model" (PAM) achievable e.g. by pairwise-key PKI.
>
>
>
> What is "pairwise-key PKI"?
>
> pair-wise set of private/public key, i.e. a designated key pair per port. I'll try
> to word it better
>
>
>  Secion 5.4.2 says "Low processing overhead and efficiency messaging are also a
> goal."
>
>
>
> I suggest replacing efficiency with efficient
>
> ack
>
>  It also says "Message privacy achieved through full encryption is a non-goal"
>
>
>
> I suggest saying "Message confidentiality is a non-goal" instead.
>
> ack
>
>  Section 5.4.3
>
> "Length of Fingerprint:  8 bits.  Length in 32-bit multiples of the
>
>       following fingerprint not including lifetime or nonces.  It allows
>
>       to navigate the structure when an unknown key type is present.  To
>
>       clarify a common cornercase a fingerprint with length of 0 bits is
>
>       presenting this field with value of 0."
>
>
>
> Does length 0 mean no fingerprint is present (i.e. fingerprints are not provided)?
> I don't understand that last sentence.
>
> yes, it does. I try to improve the wording.
>
>  The definition for "Security Fingerprint" includes this  sentence:
>
>
>
> "If the fingerprint is shorter than the significant bits are left aligned and
> remaining bits are set to 0."
>
>
>
> I don't understand this sentence. I think you mean that      if the fingerprint
> bit length is not an even multiple of 32, then it is left-aligned, and the
> rightmost unused bits are set to 0. But that's just a guess.
>
> yes, I try to word better.
>
>  5.4.4
>
> "Any implementation including RIFT security MUST generate and wrap around local
> nonces properly"
>
>
>
> I see the term "nonce" used elsewhere, but because it can wrap (and therefore
> repeat with regularity),
> I think this is a poor choice for naming this field. It seems to be more of a
> counter.
> I think most security folks would agree that a nonce used for security purposes
> should,
> by definition, repeat only with negligible probability.
>
> I was under the impression that nonce is a well-known term in cryptography
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Cryptographic-5Fnonce&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=at8GTl8R0Z06MPVIsuXx0_C74NJeGZ1xePUdjnYACtg&e=
> [https://urldefense.proofpoint.com/v2/url?u=https-3A__upload.wikimedia.org_wikipedia_commons_thumb_4_4f_Nonce-2Dcnonce-2Duml.svg_1200px-2DNonce-2Dcnonce-2Duml.svg.png&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=sxN_f34c3v2_yMpEZgquYcJbHLXu8PmtP6nDuaIkmlc&e=]<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Cryptographic-5Fnonce&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=at8GTl8R0Z06MPVIsuXx0_C74NJeGZ1xePUdjnYACtg&e=>
>
> Cryptographic nonce -
> Wikipedia<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Cryptographic-5Fnonce&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=at8GTl8R0Z06MPVIsuXx0_C74NJeGZ1xePUdjnYACtg&e=>
> In cryptography, a nonce is an arbitrary number that can be used just once in a
> cryptographic communication. It is similar in spirit to a nonce word, hence the
> name.It is often a random or pseudo-random number issued in an authentication
> protocol to ensure that old communications cannot be reused in replay attacks.They
> can also be useful as initialization vectors and in cryptographic hash ...
> en.wikipedia.org
>
>
>
>  On a related note, does this really provide anti-replay protection?
> Elsewhere in the document (e.g. section 5.4.4) it says that implementations could
> go up to
> 5 minutes without incrementing nonces. Can they send multiple packets with the
> same
> nonce during this interval? If so, what prevents replay of a captured packet
> within that interval?
>
>
>
> Also, because wrapping (of this 16 bit value) is supported, it's also possible
> that an earlier packet could be replayed (assuming the peer nonce also aligned),
> right? The odds of this seem low, but could the protocol/endpoint states be
> manipulated to improve the odds? Not sure. But if you are assuming this can't
> happen, this security-relevant assumption should be called out.
>
>
>
>   1.  Correct, for efficieny purposes we open up to a 5 min window which we
> consider an acceptable risk per point 2
>   2.  it is the combination of local and remote nonce so it's really a 32 bit
> number. The chance that the combination repeats is obviously very small.
>
>
>  5.4.7 says
>
>
>
>    "If an implementation supports disabling the security envelope
>
>    requirements while sending a security envelope an implementation
>
>    could shut down the security envelope procedures while maintaining an
>
>    adjacency and make changes to the algorithms on both sides then re
>
>    enable the security envelope procedures but that introduces security
>
>    holes during the disabled period."
>
>
>
> Aside from the fact that this needs word-smithing, should this be called out in
> the security
> considerations section? This eeems to be saying that it's not a good idea to
> temporarily
> maintain adjacency while disabling security, so is this a SHOULD NOT?
>
>
> Will improve wording. Yes, it is a SHOULD NOT but sometimes implementations do
> that to not loose adjacency and change keys easily.
>
>
>  section 8.4
>
> flodding -> flooding
>
>
>
> section 8.4 also says
>
>
>
>    It is expected that an
>
>    implementation detecting too many fake losses or misorderings due to
>
>    the attack on the number would simply suppress its further processing.
>
>
>
> what are "fake losses"?
>
>
>
> I am not a routing expert, so there may be additional concerns that someone better
> versed in routing would raise.
> Will improve wording. "Fake losses" is a possible attack vector where an attacker
> intercepts packets, modifies the packet number  to simulate a "packet number
> loss/misorder" and forwards the packet on.
>
> Please fwd' to reviewer if needed & tell me whether you want notification on new
> version ...
>
> --- tony
>
> ________________________________
> From: Jeffrey (Zhaohui) Zhang
> Sent: Thursday, April 18, 2019 7:26 AM
> To: Antoni Przygienda
> Subject: RIFT security review
>
> Hi Tony,
>
> Please see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dietf-2Drift-2Drift-2D04-2Dsecdir-2Dearly-2Dkelly-2D2019-2D04-2D11_&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ewT6IR2ygwqlSkxXUvque4qSUqKng8_ycsGJH_mNH6U&s=ph0HbUWIyvt-sCe809MFpw7LlO3iXVYLDPyoZ6Uze10&e=.
>
> Thanks.
> Jeffrey
>
> Juniper Internal
>