From nobody Mon Oct 25 15:44:52 2021 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AFB3A0BB0 for ; Mon, 25 Oct 2021 15:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.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 3j83FlKRmp4e for ; Mon, 25 Oct 2021 15:44:46 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 5D1193A08C4 for ; Mon, 25 Oct 2021 15:44:31 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id s4so1167419uaq.0 for ; Mon, 25 Oct 2021 15:44:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qeIOtwOGriY6Jrw5Wq3hFQ6QWtLKCXWlP3xCegsSn1Q=; b=W+/5V9qWRv7Sjxg+W9jkw099UIjGbTRU4LSrnGvmFu67r55nyRpejncuy6NZu8HnZs JMTqqzXa/5MveQXkwEOIZj5TwWttAOHv8y6BvGNTk+h7elLT8H7icPpVp3Zq1IXIBKzG hTylmvXmqLbi4+y1IchsAI55veNJcq/lpX0tSbzebzmJlC/Mu3kAa9+wzC1R2ni57RYL 404UN/rXFBUiyN2mH7SYrDorjdJsarMqGV+94oMUj9dNc0tnfWOpSYa44G9aMFB0LFi6 Y49wwnbaVhy1VtDJPPl9ioMVNZP8BMd4+uDjaTxVqMta4gt3jf5L1U4l5OMfoQfoi4t9 uQhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qeIOtwOGriY6Jrw5Wq3hFQ6QWtLKCXWlP3xCegsSn1Q=; b=MQovt/UBTPuq9316r2tybd2Q5GDbK3DesmrkV5ROg0G40CkhMm+uvgfcuzyRKS1286 4yAFfY9ExjppPrTWLZBDOOVlJzBGAT7fTlBa2cxv5Y+9mDdOfdo2RQ6TmXu7gAAGbPeU R54a7rbkWHS4SltyGLsIwPPhuVEMiqlDvqgKGhadXVsRdzi/6HJriFLNvDNYJUTNyv2Q eSYEVBpikE+baxa/aPsOhPmc+UddsH/rJ4Fvlb/16rfN1hyBoTFfSGbv6mE9cxvDLOyL BzYuLM2UBo3ltgqZ6PfcJfRrZAzhUWEUZXLYElveob6gLTkL2oLQ76v2hoVUen/n4VJ3 6shA== X-Gm-Message-State: AOAM5321ElkurV46AvluY2WVV1lk8ucg6qiQ9cPERjZrawBZzt5lS4Zq I43hGDkPGS7SukheC+WKAIMne/0sFTJbvecNUOEuUg== X-Google-Smtp-Source: ABdhPJyThhHrqTj6AA5CiLQMgZtEGSejMYCp4Pn4iUJQVJS/+mwwvzwq2uteorh4xwjnx81W3u4P3ItM89/9OwaS/Rc= X-Received: by 2002:a05:6102:115b:: with SMTP id j27mr9113480vsg.7.1635201868928; Mon, 25 Oct 2021 15:44:28 -0700 (PDT) MIME-Version: 1.0 References: <1F31CC6F-8471-4B50-AE3F-9E5FC76BB447@employees.org> <0C1C8148-3D59-4C2A-A834-5B11854B3E7C@liquidtelecom.com> In-Reply-To: <0C1C8148-3D59-4C2A-A834-5B11854B3E7C@liquidtelecom.com> From: Warren Kumari Date: Mon, 25 Oct 2021 18:43:52 -0400 Message-ID: To: Andrew Alston Cc: Gert Doering , Brian E Carpenter , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000088ac3a05cf351a7e" Archived-At: Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 22:44:52 -0000 --00000000000088ac3a05cf351a7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2021 at 6:18 PM Andrew Alston wrote: > It would help to have a dedicated prefix - as a start - does it really > solve the issue though. > That depends on what we are meaning by "the issue" -- I think that it is more "issues" :-) What it does do is allow me to filter out *your* SRH traffic at my border ingress (and also makes it easier for you to filter at egress) - this gets us something that looks and behaves much more like an MPLS edge. I fully agree that it doesn't protect against a compromised host that is participating in the limited domain itself -- but, hopefully it does limit some of the fallout from that to just within the domain itself. Sorry to sound uncaring, but if you end up with a compromised server creating malicious packets within your SRH domain, I'd much rather that they only affect you and not me :-) Having a crunchy edge may also help with determining what should actually participate in the limited domain -- if you include a stack of cloud servers participating in SRH, yes, they are now able send SRH packets. This is a conscious decision that you've made -- it might be a perfectly fine one, but you've intentionally extended the edge of the domain to include this. In my ideal scenario, this prefix is by default filtered, and you'd need to explicitly allow it on a per interface basis. > > Imagine a device with a stack of cloud servers behind it - each server > terminates on a separate sub-interface - and now you're trying to apply > what is in effect an LPM filter to each and every interface (as compared = to > host based firewalling or other security mechanisms) - my question is the= n > - how far will your tcam go - how practical is this in reality. > > This is as opposed to if there is a separate ether-type where an interfac= e > is either configured to process it or drop it on the floor. I much much prefer a separate ether-type -- but I suspect that that ship has sailed. > So yes - the prefix filtering will help - but I suspect that you're gonna > find many many scenarios where this actually doesn=E2=80=99t work - and a= ll you > need is *one* filter miss that has a compromised server behind it to have > real problems. > > Something I haven't got around to fully testing yet - but let me throw ou= t > an interesting scenario on my list of tests to do. > > Rogue host A takes an IPv4 packet and encapsulates it in an SRH - the > First sid in there is any v6 router you like on the path - the packet get= s > there - it get de-encapped - same as everything I've said before. I'm assuming that in this scenario your "Rogue host A" is one that has intentionally added to the SRH domain (either by allowing your new ether-type, or manually removing the "limited domain prefix filter")? If so, then yes, bad things happen. This seems largely the same as "I decided to add "Rogue host A" to my MPLS domain so it could MPLS", or I added "Rogue host A" to my IGP, because reasons... Making a host able to influence routing, whether it is part of something like MPLS, SR, or in your IGP makes that host able to do bad things... W Now - the inner packet is a v4 packet - it has a source set to random host > attacker doesn=E2=80=99t like - and its destination is 255.255.255.255 -= which > thanks to rfc919 will not forward - when that deencap happens - does the > packet get dropped because it can't be forwarded - or does it get treated > as a local broadcast. This is a rather undefined scenario - if however i= t > DOES get treated as a local broadcast - well - then we have a really big > problem - that=E2=80=99s called smurf-v2 (and even if 255.255.255.255 doe= sn=E2=80=99t work > - more specific broadcasts that are attached may well work). At this poin= t > - when the broadcast packet hits the hosts behind those broadcasts - they > will reply to the spoofed source - this will follow stock standard routin= g > outbound - and the protections we would normally use aren=E2=80=99t gonna= work (the > source of replies to the broadcast packets would be the hosts - they are > permitted to send packets to the internet) > Another scenario - sending to multicast addresses post de-encap - do we > have a potential attack vector to poison ND? Again - haven't had the tim= e > to test this. > > Same thing applies to a whole long list of other things - effectively - i= f > you get one compromised host on the network that can inject a packet that > will de-encap and act on the inner packet - with absolutely zero mechanis= ms > for verification of what is in that inner packet or how to handle it - th= e > list of possible problems is - extensive to say the last. All I am sayin= g > is - we need to really step back and think - and I think this needs a > veryyyyy close look - because in initial tests I have done - and without > the above additional tests - I can tell you my results are looking > positively scary (and once I complete the full set I'll publish some > scenarios and results with more detail) > > Andrew > > > =EF=BB=BFOn 26/10/2021, 00:48, "v6ops on behalf of Gert Doering" < > v6ops-bounces@ietf.org on behalf of gert@space.net> wrote: > > Hi, > > On Tue, Oct 26, 2021 at 10:44:32AM +1300, Brian E Carpenter wrote: > > On 26-Oct-21 10:31, Gert Doering wrote: > > > On Mon, Oct 25, 2021 at 05:20:51PM -0400, Warren Kumari wrote: > > >> I somewhat like the idea of having a well known prefix for > "limited > > >> domains" > > > > fc00::/7 works well. RFC8994 is a worked example. > > So how would that work for an ISP network trying to run SR6, protecti= ng > its network from rogue hosts inside? Without having GUAs on the SR6 > routers that would happily decapsulate incoming SR6 packets, and > without violating lots of rules about "do not leak ULAs outside > your network" (traceroute and other ICMP errors)? > > I lack imagination today... > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, > Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --00000000000088ac3a05cf351a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 25, 2021 at 6:18 PM Andre= w Alston <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote:
It would help to have a dedicated= prefix - as a start - does it really solve the issue though.

That depends on what we are meaning=C2=A0by "th= e issue" -- I think that it is more "issues" :-)
<= br>
What it does do is allow me to filter out *your* SRH traffic = at my border ingress (and also makes it easier for you to filter at egress)= - this gets us something that looks and behaves much more like an MPLS edg= e.

I fully agree that it doesn't protect again= st a compromised=C2=A0host that is participating in the limited domain itse= lf -- but, hopefully it does limit some of the fallout from that to just=C2= =A0within=C2=A0the domain itself. Sorry to sound uncaring, but if you end u= p with a compromised server creating malicious packets within your SRH doma= in, I'd much rather=C2=A0that they only=C2=A0affect you and not me :-)<= /div>
Having a crunchy edge may also help with determining what should = actually participate in the limited domain -- if you include a stack of clo= ud servers participating in SRH, yes, they are now able send SRH packets. T= his is a conscious decision that you've made -- it might be a perfectly= fine one, but you've intentionally=C2=A0extended the edge of the domai= n to include this. In my ideal scenario, this prefix is by default filtered= , and you'd need to explicitly allow it on a per interface basis.
=
=C2=A0

Imagine a device with a stack of cloud servers behind it - each server term= inates on a separate sub-interface - and now you're trying to apply wha= t is in effect an LPM filter to each and every interface (as compared to ho= st based firewalling or other security mechanisms) - my question is then - = how far will your tcam go - how practical is this in reality.

This is as opposed to if there is a separate ether-type where an interface = is either configured to process it or drop it on the floor.=C2=A0

I much much prefer a separate ether-type -- but I s= uspect that that ship has sailed.
=C2=A0
So yes - the prefix filtering will help - = but I suspect that you're gonna find many many scenarios where this act= ually doesn=E2=80=99t work - and all you need is *one* filter miss that has= a compromised server behind it to have real problems.

Something I haven't got around to fully testing yet - but let me throw = out an interesting scenario on my list of tests to do.

Rogue host A takes an IPv4 packet and encapsulates it in an SRH - the First= sid in there is any v6 router you like on the path - the packet gets there= - it get de-encapped - same as everything I've said before.=C2=A0

I'm assuming that in this scenario your &qu= ot;Rogue host A" is one that has intentionally=C2=A0added to the SRH d= omain (either by allowing your new ether-type, or manually removing the &qu= ot;limited domain prefix filter")? If so, then yes, bad things happen.= This seems largely the same as "I decided to add "Rogue host A&q= uot; to my MPLS domain so it could MPLS", or I added "Rogue host = A" to my IGP, because reasons...=C2=A0
Making a host able to= influence routing, whether it is part of something=C2=A0like MPLS, SR<s= omething>, or in your IGP makes that host able to do bad things...=C2=A0=

W=C2=A0


Now - the inner packet is a v4= packet - it has a source set to random host attacker doesn=E2=80=99t like = - and its destination is 255.255.255.255=C2=A0 - which thanks to rfc919 wil= l not forward - when that deencap happens - does the packet get dropped bec= ause it can't be forwarded - or does it get treated as a local broadcas= t.=C2=A0 This is a rather undefined scenario - if however it DOES get treat= ed as a local broadcast - well - then we have a really big problem - that= =E2=80=99s called smurf-v2 (and even if 255.255.255.255 doesn=E2=80=99t wor= k - more specific broadcasts that are attached may well work). At this poin= t - when the broadcast packet hits the hosts behind those broadcasts - they= will reply to the spoofed source - this will follow stock standard routing= outbound - and the protections we would normally use aren=E2=80=99t gonna = work (the source of replies to the broadcast packets would be the hosts - t= hey are permitted to send packets to the internet)=C2=A0

Another scenario - sending to multicast addresses post de-encap - do we hav= e a potential attack vector to poison ND?=C2=A0 Again - haven't had the= time to test this.

Same thing applies to a whole long list of other things - effectively - if = you get one compromised host on the network that can inject a packet that w= ill de-encap and act on the inner packet - with absolutely zero mechanisms = for verification of what is in that inner packet or how to handle it - the = list of possible problems is - extensive to say the last.=C2=A0 All I am sa= ying is - we need to really step back and think - and I think this needs a = veryyyyy close look - because in initial tests=C2=A0 I have done - and with= out the above additional tests - I can tell you my results are looking posi= tively scary (and once I complete the full set I'll publish some scenar= ios and results with more detail)

Andrew


=EF=BB=BFOn 26/10/2021, 00:48, "v6ops on behalf of Gert Doering" = <v6ops-bounc= es@ietf.org on behalf of gert@space.net> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 On Tue, Oct 26, 2021 at 10:44:32AM +1300, Brian E Carpenter w= rote:
=C2=A0 =C2=A0 > On 26-Oct-21 10:31, Gert Doering wrote:
=C2=A0 =C2=A0 > > On Mon, Oct 25, 2021 at 05:20:51PM -0400, Warren Ku= mari wrote:
=C2=A0 =C2=A0 > >> I somewhat like the idea of having a well known= prefix for "limited
=C2=A0 =C2=A0 > >> domains"
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > fc00::/7 works well. RFC8994 is a worked example.

=C2=A0 =C2=A0 So how would that work for an ISP network trying to run SR6, = protecting
=C2=A0 =C2=A0 its network from rogue hosts inside?=C2=A0 Without having GUA= s on the SR6
=C2=A0 =C2=A0 routers that would happily decapsulate incoming SR6 packets, = and
=C2=A0 =C2=A0 without violating lots of rules about "do not leak ULAs = outside
=C2=A0 =C2=A0 your network" (traceroute and other ICMP errors)?

=C2=A0 =C2=A0 I lack imagination today...

=C2=A0 =C2=A0 Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 have you enabled IPv6 on something today...?

=C2=A0 =C2=A0 SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard, Michael Emmer =C2=A0 =C2=A0 Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsicht= sratsvors.: A. Grundner-Culemann
=C2=A0 =C2=A0 D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0HRB: 136055 (AG Muenchen)
=C2=A0 =C2=A0 Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt= -IdNr.: DE813185279

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


--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--00000000000088ac3a05cf351a7e--