Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12

Robert Raszuk <robert@raszuk.net> Wed, 12 June 2019 16:50 UTC

Return-Path: <robert@raszuk.net>
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 68C24120088 for <idr@ietfa.amsl.com>; Wed, 12 Jun 2019 09:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 vlNDBhsJQPJb for <idr@ietfa.amsl.com>; Wed, 12 Jun 2019 09:50:45 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 127FE1201D3 for <idr@ietf.org>; Wed, 12 Jun 2019 09:50:44 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id x47so19194156qtk.11 for <idr@ietf.org>; Wed, 12 Jun 2019 09:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=imrUJnHZQDKN7pfh3nLPIjgrat4fMrBpwzBh3d8bhes=; b=MxmUTpB0KI1NGFF7fkM7usmo71svrOK+I+Inasv7OP4v46dKcwRijMOmCNKzvXBV+r Upo/d2VoHuv2Ujvj9S6wI2R4CMQsUdmvSxLUTgo8LqIAV3tWkbWbt82ZilRqFgWMImgy Lr/oVchWr+Af1gEWb+BEyqNZHkoOl/ju4ciJJzC624AwmEGdRq69IxZt4n1VzEslsPf9 WT9cHgxLA1uzyIIeH8IunobJuIQYLWCFWntKSPiHPaSPhbFd9hTF+UoFIEq6cYMFxpU1 IHum/OStFoNeqBxOiACa3DwdBN6MOcLKWhW/5OmvVb0hz4OyWJuXJOFfdxIf8ik9QZsR Xizg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=imrUJnHZQDKN7pfh3nLPIjgrat4fMrBpwzBh3d8bhes=; b=g2q4SAeeopYoq2H8n7Uzf7rH486p8Lon5k00qmntQuKtbEp9yKZwhmUJe2KsjL5tjV ZjtkkaQ9za8wwlqNBp7R1TAFp2+n3ORXv6PR7R7emJBc26kni2AOPSZqFwnJObEWsrf1 8aZXQniehvcKPUZcybTxG4CoMzMdrHRTvFJ92MISUwACVamoSuxYiacHzLxyBKpxdJTL f2KqXbyXutBKnrULr8Eanq0zI5T010ipsS7kPj59oJYtZRblm3Ij9j6SIAa2xLvogY6g TrckP8QpiQb3WK/rwSFELHVHDbA6Vwf3pLdjhLC6vQGQJRj98d2hKD81QzRH0DtwRy0b jqpg==
X-Gm-Message-State: APjAAAUlMQ6Hj6Oc5g4zDnw/T/feoIy8QvDwrJZnT6C3WRj7ODU9q0TM GZdpo2fKYaNdFJa0s56RksfF38IN1784vv9rVllgYajY
X-Google-Smtp-Source: APXvYqw77sRxtn/e2pnSWdbfZrsuaq94toM7r5/NlKMbh/UDLsOcHIX7d+12Uu5mGVwh7tUTEmipcJPPrmGXjPhzqGI=
X-Received: by 2002:aed:382a:: with SMTP id j39mr69689753qte.94.1560358242809; Wed, 12 Jun 2019 09:50:42 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB358247036D97F6620E2CB987A9130@MN2PR13MB3582.namprd13.prod.outlook.com> <234E41A5-F754-4630-B73C-8A9D52E44198@juniper.net> <6691B6FF-E9F5-4E9B-8D91-E8371993EDB5@juniper.net> <MN2PR13MB35826173FB5AC8D019497438A9ED0@MN2PR13MB3582.namprd13.prod.outlook.com> <5E89EE56-8852-4A1C-B072-EFE15ADA2618@juniper.net> <9E64708F-5E78-422C-8339-3447529BABB4@arrcus.com> <CAOj+MMFVhNFUnAe-QxyWHX65PY=VQmCK0N5aOcx=5nAApX5z4g@mail.gmail.com> <54873561-EFB8-4047-BF9C-74A42BBC5BDA@arrcus.com>
In-Reply-To: <54873561-EFB8-4047-BF9C-74A42BBC5BDA@arrcus.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 12 Jun 2019 18:50:28 +0200
Message-ID: <CAOj+MMGW9tAm=-X2Z4ed1_stsO_QwYSE-09xhubDu7MUULUTyg@mail.gmail.com>
To: Keyur Patel <keyur@arrcus.com>
Cc: John Scudder <jgs@juniper.net>, Linda Dunbar <ldunbar@futurewei.com>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c9135a058b233671"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jQyqIAox7497ENBgppqYz0exS_w>
Subject: Re: [Idr] recap my questions and issues raised during IDR Thurs session for draft-ietf-idr-tunnel-encaps-12
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: Wed, 12 Jun 2019 16:50:49 -0000

Hi,

So when A is creating the update to be send to B for A the meaning of the
sub-TLV is really a "local tunnel endpoint".

When the update is received at B the same very field in the sub-TLV now
becomes the tunnel destination so it indeed is a  "remote tunnel endpoint".

And then when such update is injected by say third party (for example
controller) neither of this applies when the update is being created.

Therefor why not to simply call the field as "tunnel endpoint address" ?
The "remote" word seems to be only generating confusion here.

To add to this let's observe that the tunnel will be bi-direction in vast
majority of cases. So the same field now when stored in the OS means
different things depending if this is a locally configured/originated value
to be send to a peer(s) or remote value learned from the peer(s).

And it is a bit unfortunate but the word "remote" is heavily used in the
document today. IMO use of remote should always be associated with the
reference of from who's perspective it is to be "remote"

Thx,
R.


On Wed, Jun 12, 2019 at 6:34 PM Keyur Patel <keyur@arrcus.com> wrote:

> My comments are inlined #Keyur1
>
>
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Wednesday, June 12, 2019 at 3:07 AM
> *To: *Keyur Patel <keyur@arrcus.com>
> *Cc: *John Scudder <jgs@juniper.net>, Linda Dunbar <ldunbar@futurewei.com>,
> "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <
> draft-ietf-idr-tunnel-encaps@ietf.org>
> *Subject: *Re: [Idr] recap my questions and issues raised during IDR
> Thurs session for draft-ietf-idr-tunnel-encaps-12
> *Resent-From: *<keyur@arrcus.com>
>
>
>
> Hey,
>
>
>
> > #Keyur: Completely agree. Remote Endpoint is clearly not constrained to
> represent only the BGP speaker.
>
>
>
> That is not the question here.
>
>
>
> Draft is really not clear in its current state to define what or who the
> "remote endpoint" is. See there are two endpoints and each is the remote
> for the other :).
>
>
>
> See I have two BGP speakers: A----B
>
>
>
> If A sends an update to B with field of "remote endpoint" does this field
> apply to A or B ? Is it remote from sender perspective or receiver
> perspective of BGP update. That is the dilemma here.
>
>
>
> #Keyur1: In this specific example assuming A originated the route and
> remote endpoint, then it is from B’s perspective. It is the endpoint
> address to which the tunnel is established.
>
>
>
> Regards,
>
> Keyur
>
>
>
> So I agree with Linda that it is in our common interest to define it well
> before final publication.
>
>
>
> And I do not share John's point that this falls into "rough consensus"
> category if he, Linda, Jun and me and I am sure bunch of other folks
> reading it while trying to implement will also be unclear. To me it rather
> falls into - "insufficient review" bucket.
>
>
>
> Thx,
> R.
>
>
>
>
>
> On Wed, Jun 12, 2019 at 6:29 AM Keyur Patel <keyur@arrcus.com> wrote:
>
> My comments are inlined #Keyur
>
>
>
> *From: *John Scudder <jgs@juniper.net>
> *Date: *Tuesday, June 11, 2019 at 2:07 PM
> *To: *Linda Dunbar <ldunbar@futurewei.com>
> *Cc: *Keyur Patel <keyur@arrcus.com>, "
> draft-ietf-idr-tunnel-encaps@ietf.org" <
> draft-ietf-idr-tunnel-encaps@ietf.org>, "idr@ietf.org" <idr@ietf.org>
> *Subject: *Re: [Idr] recap my questions and issues raised during IDR
> Thurs session for draft-ietf-idr-tunnel-encaps-12
> *Resent-From: *<keyur@arrcus.com>
>
>
>
> (Still as a WG contributor…)
>
>
>
> Hi Linda,
>
>
>
> On Jun 11, 2019, at 4:41 PM, Linda Dunbar <ldunbar@futurewei.com> wrote:
>
>
>
> John,
>
>
>
> Before I elaborate for more scenarios, I would like to get the answer to
> the following question:
>
>
>
>    - Does the “Remote Endpoint” in draft-ietf-idr-tunnel-encaps-12
>    represent the BGP speaker that originates the update? Or the remote end
>    point that the “Tunnel” is established to?
>
>
>    - I have been told two different versions of the answers. I need
>       confirmation from the authors.
>
>
>
> I’m not an author of course but I’ll provide my own reading for the sake
> of continuing the discussion. I just reviewed section 3.1 of the draft, and
> based on that review it’s my opinion that the Remote Endpoint is clearly
> not constrained to represent only the BGP speaker that originates the
> update. Reasons for thinking this include:
>
>
>
> - There is no text stating that it’s so constrained. “Everything is
> permitted except that which is forbidden.”
>
> - There is a detailed set of validation procedures. If the authors had
> wanted this constraint, it seems unlikely they would have just forgotten to
> put it in the set of procedures.
>
> - There is special case text that says if the AF subfield is 0, the remote
> endpoint is inferred from the NH. “The exception proves the rule."
>
>
>
> #Keyur: Completely agree. Remote Endpoint is clearly not constrained to
> represent only the BGP speaker.
>
>
>
> Regards,
>
> Keyur
>
>
>
>
>
> Furthermore, the first two paragraphs of section 9, while they don’t
> explicitly say a third-party route is being used, only make sense in that
> context, so that’s yet more evidence that this is the correct reading.
> Finally, the first paragraph of the Security section has the same
> implication.
>
>
>
>
>    -
>
> Can a node R send Tunnel-Encap update with “remote endpoint” being A?
>
>
>
> Based on the above, my answer would be “yes”. (Subject to the various
> validation procedures listed in the draft, of course.)
>
>
>
> The Section 13 suggests “BGP Origin Validation [RFC6811] can be used”.
> But “BGP Origin Validation” is only to validate the Speaker, correct?
>
>
>
> No. The TL;DR of RFC 6811 is that
>
>
>
> - There’s a database (the RPKI) that lists (in a cryptographically secure
> way) what ASes are allowed to originate what prefixes
>
> - A router can check a route against that database, considering the prefix
> and origin AS:
>
> - If they’re found in the RPKI, the route is considered valid
>
> - If no assertion about the prefix is found in the RPKI, the route is
> considered not found.
>
> - If an assertion is found in the RPKI but it doesn’t match what was found
> in the update, the route is considered invalid.
>
>
>
> You will note this has nothing to do with the speaker that provided the
> update, it relates only to the contents of the route.
>
>
>
> Naturally this is only a quick summary, from memory. If you want
> authoritative detail you should refer to RFC 6811 itself. It's short and
> (IMHO :-) readable.
>
>
>
> doesn’t seem to address the security scenario being described.
>
>
>
> Maybe my description of RFC 6811 helps?
>
>
>
> Regards,
>
>
>
> —John
>
>
>
>
>
> Linda
>
>
>
> *From:* John Scudder <jgs@juniper.net>
> *Sent:* Monday, June 10, 2019 5:26 PM
> *To:* Linda Dunbar <ldunbar@futurewei.com>
> *Cc:* Keyur Patel <keyur@arrcus.com>;
> draft-ietf-idr-tunnel-encaps@ietf.org; idr@ietf.org
> *Subject:* Re: [Idr] recap my questions and issues raised during IDR
> Thurs session for draft-ietf-idr-tunnel-encaps-12
>
>
>
> (Still as a WG contributor)
>
>
>
> A little bit more on this.
>
>
>
> Your comments led me to go look back at the draft’s Security section
> again. The first paragraph reads
>
>
>
>    The Tunnel Encapsulation attribute can cause traffic to be diverted
>
>    from its normal path, especially when the Remote Endpoint sub-TLV is
>
>    used.  This can have serious consequences if the attribute is added
>
>    or modified illegitimately, as it enables traffic to be "hijacked".
>
>
>
> This seems like an explicit acknowledgement of the general class of attack
> you describe.
>
>
>
> It might be helpful if you provide a worked example of a specific attack
> that would succeed against a tunnel-encaps implementation, but would not
> succeed against a 5512 implementation. I can’t think of one off the top of
> my head, but you clearly have something in mind.
>
>
>
> Thanks,
>
>
>
> —John
>
>
>
>
>
> On Jun 10, 2019, at 6:16 PM, John Scudder <
> jgs=40juniper.net@dmarc.ietf.org> wrote:
>
>
>
> (As a WG contributor)
>
>
>
> Hi Linda,
>
>
>
> I have a question for you — when you say RFC5512 doesn’t allow a third
> party to inject routes on behalf of a legitimate router, what do you think
> would prevent it? You mention the endpoint address in the NLRI, but what
> would prevent the malicious entity you mention for from falsifying it?
>
>
>
> Thanks,
>
>
>
> —John
>
>
>
> On Jun 10, 2019, at 4:47 PM, Linda Dunbar <ldunbar@futurewei.com> wrote:
>
>
>
> Keyur,
>
>
>
> Thank for the email.
>
> One more question:
>
>    - Does the “Remote Endpoint” in draft-ietf-idr-tunnel-encaps-12
>    represent the BGP speaker that originates the update? Or the remote end
>    point that the “Tunnel” is established to?
>
>
>    - I have been told two different versions of the answers. I need
>       confirmation from the authors.
>
>
>
>
>
> Reading through the Section 13 Security Consideration, I don’t think the
> following questions have been addressed:
>
>
>
>    1. In RFC5512, the BGP speaker indicates the originating Interface
>    address in the NLRI (section 3):
>
>
>
> <image001.png>
>
>
>
> Questions:
>
>
>
>    - draft-ietf-idr-tunnel-encaps-12  no longer has the BGP speaker
>    originating the update. Is it intended?
>
>
>
>
>
> If Yes, does it mean that it allows a third party (which could be
> malicious entity) to inject routes on behalf of a legitimate router (but
> RFC5512 doesn’t)?
>
>
>
>    - Why add this scenario? If it is a conscious decision, should have
>    some text to explain why and how to mitigate the security threats
>    introduced.
>
>
>
>    - Section 13 suggests using BGP Origin Validation to obtain the
>    additional assurances of the origin AS is valid. But being valid origin AS
>    doesn’t mean the specific flow is supposed to go/come from there.
>
>
>
>
>
> #Keyur: Section 13 of the draft version 12 describes Security
> Considerations that should address your security questions. The option is
> to provide flexibility.
>
>
>
>
>
> Thank you,
>
>
>
> Linda Dunbar
>
>
>
> *From:* Keyur Patel <keyur@arrcus.com>
> *Sent:* Saturday, June 08, 2019 3:45 AM
> *To:* Linda Dunbar <ldunbar@futurewei.com>;
> draft-ietf-idr-tunnel-encaps@ietf.org; idr@ietf.org
> *Cc:* John Scudder <jgs@juniper.net>
> *Subject:* Re: recap my questions and issues raised during IDR Thurs
> session for draft-ietf-idr-tunnel-encaps-11
>
>
>
> Hi Linda,
>
>
>
> Apologies for the delayed response. Responses are inline. #Keyur
>
>
>
> *From: *Linda Dunbar <linda.dunbar@huawei.com>
> *Date: *Thursday, March 28, 2019 at 6:52 AM
> *To: *idr wg <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <
> draft-ietf-idr-tunnel-encaps@ietf.org>
> *Subject: *recap my questions and issues raised during IDR Thurs session
> for draft-ietf-idr-tunnel-encaps-11
> *Resent-From: *<keyur@arrcus.com>
> *Resent-To: *<erosen52@gmail.com>, <keyur@arrcus.com>, <
> gunter.van_de_velde@nokia.com>
> *Resent-Date: *Thursday, March 28, 2019 at 6:52 AM
>
>
>
> Just want to reiterate my questions and issues I raised during IDR Thurs
> session for draft-ietf-idr-tunnel-encaps-11, to make it easier for the
> authors to address them in the next revision (I have sent the questions
> multiple times on the IDR mailing list, but no one responded):
>
>
>
>    1. When a client route can egress multiple egress ports (each with
>    different IP addresses), does the Tunnel-Encap allow multiple
>    “Remote-endpoint” SubTLV to be attached one UPDATE?
>
>
>
> #Keyur: Yes. Section 5 of the draft version 12 has a following  text:
>
>
>
> <snip>
>
> A Tunnel Encapsulation attribute may contain several TLVs that all
>
>    specify the same tunnel type.  Each TLV should be considered as
>
>    specifying a different tunnel.  Two tunnels of the same type may have
>
>    different Remote Endpoint sub-TLVs, different Encapsulation sub-TLVs,
>
>    etc.  Choosing between two such tunnels is a matter of local policy.
>
> </snip>
>
>
>
>
>
>    1. Section 3.1 Page 10: The last paragraph states that if
>    “Remote-Endpoint sub-TLV contains address is valid but not reachable, and
>    the containing TLV is NOT be malformed ..”. Why a address not reachable is
>    considered as “Not Malformed”?
>
>
>
> #Keyur: That is because the Remote-Endpoint could become reachable at the
> later time. Making it malformed would mean that the Remote-Endpoint has to
> be dropped upon a receipt of the update message (and could never be used).
>
>
>
>
>
>    1. In RFC5512, the BGP speaker indicates the originating Interface
>    address in the NLRI (section 3):
>
>
>
> <image001.png>
>
>
>
> draft-ietf-idr-tunnel-encaps-11  no longer has the BGP speaker originating
> the update. Is it intended? If Yes, does it mean that it allows a third
> party (which could be malicious entity) to inject routes on behalf of a
> legitimate router (but RFC5512 doesn’t)?  Why add this scenario? How to
> address the security threats introduced? If it is a conscious decision,
> should have some text to explain why and how to mitigate the security
> threats introduced.
>
>
>
> #Keyur: Section 13 of the draft version 12 describes Security
> Considerations that should address your security questions. The option is
> to provide flexibility.
>
>
>
> Regards,
>
> Keyur
>
>
>
>
>
>
>
> Thanks, Linda Dunbar
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=hLt5iDJpw7ukqICc0hoT7A&m=ss5r9k8Dew3MPUscEO1GEzNXkyfGpMlZLZUarUnS3Ys&s=_MC-6zg-U8xFzoGxuXaXYA3GVjY7anTiHQ-cuyr9Pfw&e=
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>