From nobody Fri Oct 22 11:00:22 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 DEDEF3A086A for ; Fri, 22 Oct 2021 11:00:07 -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=ham 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 fNCYZQC8Vwg2 for ; Fri, 22 Oct 2021 10:59:59 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 643D03A085F for ; Fri, 22 Oct 2021 10:59:59 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id u5so9169691uao.13 for ; Fri, 22 Oct 2021 10:59:59 -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=lHGae10RtSTgKekv6XfMB4JmKr9K6J/zknNlxDa92nA=; b=O6Pt4tZMOz3gHEOUvHlpw55EmxHP4/LqoF5sSmiGrPPJJWYpfrxr+qIYHRFZlGXpXh N2OesnyRjXHZrxs7EAStwqKkcRKNAcZJXWzLTSs8mTONJ+5+eXEA/L17ViasvJFtxtTg yknP5NFmv40iOj7lw1QPit1PbuHJmur0ZryZN6W+YikjEyrm9CV81VqDzRoGudvHx7aX se2X4q4IwieZ5AuaNXpSEJrgtV0i1wx9d18tghZkRWQqlqPMDvT4a7geaVZBoSwQf5OD 0gx2yhvYZa+pUPml6vMzqwwy9ah9uO2j8bsnlWh5NreD/X9Ocs/X25hRu8IMqgxThSN/ 7gJg== 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=lHGae10RtSTgKekv6XfMB4JmKr9K6J/zknNlxDa92nA=; b=AclqV/mGN1nE4W3DBMbebQemcTGfA/Hlz2jN/lRSQwgJqLrcspKTJDE4bZwU1t9k3B 0dUZj2xE+TAWOeYSDEGHgN+h8FgJBRoFFlpmN2xuM/fLBHK8VB7Mw2/cGE2jTpLv9hx3 8qLNClefQANVd6qn/ZnlzhkIjbX4YErW6V/udZTiFxoouotUnIufzHvLFvNwjvrMyl6R xQImW3LrjcUzoGG0bHhpAaezH5ouRYgqvrtHP9qqfMX2guJ/e1Tsfk+yI3jmpmaZLnzP RtmMCHKBHTJzASRuf40ROsTmZNZGrYhsHSe4TUi1F9uHgsomafX7z5dkXl77AZDoFgzC ZiRQ== X-Gm-Message-State: AOAM531j2BCuswCsBhRBhXozxGSwVaP/4kImrmzx3VMCTi+8UBXxEKqj Crd32Yu4JyhMdThrKOAmUMkSFafUzy0divU80DNbRA== X-Google-Smtp-Source: ABdhPJy6v6K4iy1BknViEr3fULRG4jKs4KPRnhyL4UhDRj3QnIAnDfS8eFhhx2BbrKSCLRAWS4LA+/qo40FAjPL9dP8= X-Received: by 2002:a67:3046:: with SMTP id w67mr1489429vsw.7.1634925595570; Fri, 22 Oct 2021 10:59:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Fri, 22 Oct 2021 13:59:19 -0400 Message-ID: To: Andrew Alston Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005bc60605cef4c708" 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: Fri, 22 Oct 2021 18:00:08 -0000 --0000000000005bc60605cef4c708 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 21, 2021 at 1:08 PM Andrew Alston wrote: > Hi V6Ops, > > > > I thought I would raise the issues that follow here =E2=80=93 and perhaps= we can > look and if these issues are real =E2=80=93 and if so =E2=80=93 what the = solutions are. > > > > During a close review of the compression proposals for SRv6 > (CRH/G-Srv6/USID etc etc) I noticed some potential very real > vulnerabilities in SRv6 itself =E2=80=93 which by extensions would affect= srv6, > srv6 network programming and all the compression flavors =E2=80=93 includ= ing CRH on > which I am a co-author. Having raised these issues with my CRH co-author= s > it was agreed that I raise these issues here so we could discuss them. > > > > So a little background =E2=80=93 SRrv6 is typically considered as somethi= ng that > should run in the confines of a =E2=80=9Climited-domain=E2=80=9D =E2=80= =93 the question I started > with is =E2=80=93 can we actually define and maintain the boundaries of a > limited-domain =E2=80=93 and if so =E2=80=93 how. The conclusion I came = to was that the > concept of limited-domain in regards to SRv6 was an extremely fuzzy thing= . > > > > Now to understand this =E2=80=93 we need first to look at the typical met= hods of > protecting things > > > > - In the case of MPLS =E2=80=93 we have what I will loosely refer to a= s a > =E2=80=9Cfail-closed=E2=80=9D scenario =E2=80=93 that is to say =E2=80= =93 unless MPLS is enabled explicitly > on an interface =E2=80=93 ingress packets will not be processed =E2=80= =93 this works > because of a separate ether-type > - In the case of SR-MPLS =E2=80=93 an identical situation occurs > - In the case of dodgy IGP traffic =E2=80=93 again, we have a fail-clo= sed > scenario > - In the case of standard IPv6 =E2=80=93 we have the option of utilizi= ng BCP38 > and ingress filtering =E2=80=93 and the same thing in regards to IPv4. > > Yes. "RFC 8799 - Limited Domains and Internet Protocols" says: "Domain boundaries that are defined administratively (e.g., by address filtering rules in routers) are prone to leakage caused by human error, especially if the limited domain traffic appears otherwise normal to the boundary routers. In this case, the network operator needs to take active steps to protect the boundary. This form of leakage is much less likely if nodes must be explicitly configured to handle a given limited-domain protocol, for example, by installing a specific protocol handler." There are a number of protocols which naturally have the concept of domain baked into them - you've listed some, but there are also things which primarily are L2 based, like RA and VRRP and similar. Apart from those, much of it seems to come down to "what is the default behavior for the protocol on the interface" - things like MPLS or (generally) OSPF need an intentional act to extend the edge of the domain, and also generally need the sender and receiver to both take an action. If I accidentally enable OSPF on an interface towards you, you are likely not harmed because you are not going to be willing to form an adjacency unless you have also done a stupid on the matching interface. The fact that "failure" also requires a chain (each interface/similar along a path needs config with helps with this too, as does things like authentication (which is often/usually used to prevent "Ooops" instead of malicious attacks). It feels to me like the concept of limited-domains is sometimes used like a magic incantation to avoid having to answer some of the interoperability and security questions and concerns. Saying that a protocol should (or SHOULD or MUST) only be used in a limited domain doesn't actually enforce that it will not leak. I also do not think that it is reasonable that the protection / filtering to enforce limited domains should require the (potential) recipient to have to change their filtering stance; I should not have to change my filtering policy to protect *my* network against *you* accidentally forgetting a filter at the edge of your network. If we do expect potential recipients to have to update filters, there are 2 failure modes: 1: the recipient doesn't (or misses an interface), and bad things happen or 2: we end up in the "default-deny" mode, where networks block all packets except those that they explicitly allow. This ossifies the network and makes deploying new things impossible. Networks that experience breakage of the first type will quickly move to the second option... Ed's suggestion below ("All router=E2=80=99s ports should have RH type 4 (S= RH) filtered out by default.") is already heading down this path. The way I see this playing out is operators quickly moving along the lines of: If I'm expected to filter "RH type 4 (SRH)" on all of my external interfaces in case someone else decides to run SRH, what else should I filter? Clearly 5 and 6 (CRH-16/32)... and 7, 8, ... 255. I need to be ready *before* you enable $insert_new_protocol_here, so the only sensible thing for me to do is filter all RH/43. Oh, and I don't know what sort of new uses there might be for Hop-by-Hop that might affect me, so I should clearly just filter all protocol 0 (perhaps in the future I might allow specific ones... maybe). HIP? I don't use that, but I might in the future, and I certainly don't have time to follow all of the new things being proposed in the IETF/by vendors, so obviously I should filter that everywhere... Actually, why am I bothering to write this long filter list? I'll just allow TCP and UDP, and call it done... (When I started writing the above I thought I would need to add a "Warning: Hyperbole ahead" marker -- but I'm no longer sure that that's the case). This path leads us to an ossified IPv6, and no ability to deploy new protocols. We need a solution where the border of limited-domains is clear, and automatic - and where the things touching the outside border don't need to actively protect themselves from failures of the border protection, W > > > Now =E2=80=93 lets examine SRv6 for a second. > > > > In a scenario of Host A (A linux box) with address 2001:db8:1:1::10/64 > utilizing a gateway of 2001:db8:1:1::fefe =E2=80=93 packets from 2001:d= b8:1:1::10 > flowing towards that gateway would pass ingress filter checks based on > BCP38 since the source address was legitimate, unless we explicitly > filtered out where that packet could be destined for based on its DA (Mor= e > on this in a bit) > > > > Now, lets imagine for a second that Host A gets compromised =E2=80=93 and= an > attack encapsulates a packet that has an entirely different source addres= s > =E2=80=93 and whatever random DA address inside an SRH. That SRH has a S= ID list in > it =E2=80=93 be it via a direct SID or via compression mechanisms, and a = DA towards > the SID itself. The packet then routes =E2=80=93 passing the ingress che= cks =E2=80=93 and > landing up at the router with the first SID. Since this was the only SID > in the list =E2=80=93 the packet outer SRH is removed =E2=80=93 and the i= nner packet is > forwarded to the FIB =E2=80=93 and you just bypassed BCP38. > > > > In a similar mechanism, if the SRH states that the next protocol header i= s > an IPv4 packet =E2=80=93 when the de-encapsulation happens at last SID = =E2=80=93 the > payload (the inner v4 packet) will then be forwarded via the FIB =E2=80= =93 and off > you go. > > > > Now, normally to protect against this as stated =E2=80=93 an access list = would be > placed on the networks borders to prevent encapsulated packets and packet= s > containing SID destinations from entering the network. However =E2=80=93= if we > consider the above scenario where the attack is coming from a compromised > server inside the traditional borders =E2=80=93 we have a problem. The a= pplication > of access lists to every port containing a server is also potentially > unrealistic and unmaintainable (not to mention could potentially on certa= in > devices overload the TCAMs) > > > > We also have an even more potentially deadly issue =E2=80=93 and this is = entirely > theoretical at this point since I haven=E2=80=99t had time to really inve= stigate > and test it with real code. Let us presume in the above that the same ho= st > A is compromised. It encapsulates a packet with an SRH =E2=80=93 the int= ernal > packet is an Ipv4 packet =E2=80=93 and its destined at a broadcast addres= s of an IP > subnet that is bound to the same network as the de-encapsulating router. > The source of the internal v4 packet is spoofed =E2=80=93 we=E2=80=99ve n= ow managed to =E2=80=93 > through a use of the tunneling mechanism, effectively created a version o= f > an old tool called smurf =E2=80=93 in a manner that is going to be pretty= hard to > trace. > > > > Another potential scenario =E2=80=93 would be for an attacker in host A t= o jit > some ebpf code =E2=80=93 that matches =E2=80=93 modifies and re-encapsula= tes incoming > return packets and retransmits then. Each time applying the same SRH. Th= e > inner packet could be pretty much anything =E2=80=93 so long as the inter= nal DA is > set back to host A that is sending the packet. The packet would then flo= w > out as an SRH encapsulated packet, the outer header would get popped, the > inner packet would flow back towards the original compromised host, which > would match it modify it re-encapsulate it and start the loop again. Doi= ng > this with ebpf and a kernel jit =E2=80=93 would be pretty difficult to sp= ot if you > didn=E2=80=99t know what you are doing because you wouldn=E2=80=99t poten= tially see any > obvious userland code. > > > > As a final thought =E2=80=93 consider a hypervisor based system =E2=80=93= that has > multiple VM=E2=80=99s on it =E2=80=93 and the filtering implications of a= ll of the above =E2=80=93 > and the filtering becomes even more difficult to maintain and more comple= x. > > > > Again =E2=80=93 the filtering per every port that may contains a server o= r a > desktop =E2=80=93 that may not be realistic =E2=80=93 especially when we = could be running > multiple ports that are handing out source addresses via RA =E2=80=93 so = =E2=80=93 how do > we solve this =E2=80=93 or is this a major flaw in srv6 itself =E2=80=93 = that needs some > other solution (give srv6 its own protocol code and acknowledge that it > isn=E2=80=99t ipv6 at all, allowing for a =E2=80=9Cfail-closed=E2=80=9D s= cenario maybe?) > > > > As an operator that runs extensive IPv6 =E2=80=93 I=E2=80=99d really like= to hear thoughts > and comments and potentially we can find a way to address these issues. > > > > Thanks > > > > Andrew > > > > > > > > > _______________________________________________ > 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 --0000000000005bc60605cef4c708 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 21, 2021 at 1:08 PM Andre= w Alston <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote:

Hi V6Ops,<= /p>

=C2=A0

I thought I would raise the iss= ues that follow here =E2=80=93 and perhaps we can look and if these issues = are real =E2=80=93 and if so =E2=80=93 what the solutions are.

=C2=A0

During a close review of the co= mpression proposals for SRv6 (CRH/G-Srv6/USID etc etc) I noticed some poten= tial very real vulnerabilities in SRv6 itself =E2=80=93 which by extensions= would affect srv6, srv6 network programming and all the compression flavors =E2=80=93 including CRH on which I am a co= -author.=C2=A0 Having raised these issues with my CRH co-authors it was agr= eed that I raise these issues here so we could discuss them.<= /span>

=C2=A0

So a little background =E2=80= =93 SRrv6 is typically considered as something that should run in the confi= nes of a =C2=A0=E2=80=9Climited-domain=E2=80=9D =E2=80=93 the question I st= arted with is =E2=80=93 can we actually define and maintain the boundaries = of a limited-domain =E2=80=93 and if so =E2=80=93 how.=C2=A0 The conclusion I came to was that= the concept of limited-domain in regards to SRv6 was an extremely fuzzy th= ing.

=C2=A0

Now to understand this =E2=80= =93 we need first to look at the typical methods of protecting things

=C2=A0

  • In the case of MPLS =E2=80=93 we have what I= will loosely refer to as a =E2=80=9Cfail-closed=E2=80=9D scenario =E2=80= =93 that is to say =E2=80=93 unless MPLS is enabled explicitly on an interf= ace =E2=80=93 ingress packets will not be processed =E2=80=93 this works because of a se= parate ether-type
  • I= n the case of SR-MPLS =E2=80=93 an identical situation occurs=
  • In the case of dodgy IGP traffic= =E2=80=93 again, we have a fail-closed scenario
    • <= li class=3D"gmail-m_-789071165452899518MsoListParagraph" style=3D"margin-le= ft:18pt">In the case of standard IPv6 =E2=80=93 we hav= e the option of utilizing BCP38 and ingress filtering =E2=80=93 and the sam= e thing in regards to IPv4.

<= /blockquote>
<no hats>
Yes.=C2=A0=C2=A0

<= /div>"RFC 8799 - Limited Domains and Internet Protocols" says:"Domain boundaries that are defined administratively (e.g., by addre= ss filtering rules in routers) are prone to leakage caused by human error, = especially if the limited domain traffic appears otherwise normal to the bo= undary routers. In this case, the network operator needs to take active ste= ps to protect the boundary. This form of leakage is much less likely if nod= es must be explicitly configured to handle a given limited-domain protocol,= for example, by installing a specific protocol handler."

There are a number of protocols which naturally=C2=A0have = the concept of domain baked into them - you've listed some, but there a= re also things which primarily are L2 based, like RA and VRRP and similar. = Apart from those, much of it seems to come down to "what is the defaul= t behavior for the protocol on the interface" - things like MPLS or (g= enerally) OSPF need an intentional act to extend the edge of the domain, an= d also generally need the sender and receiver to both take an action. If I = accidentally enable OSPF on an interface towards you, you are likely not ha= rmed because you are not going to be willing to form an adjacency unless yo= u have also done a stupid on the matching interface. The fact that "fa= ilure" also requires a chain (each interface/similar along a path need= s config with helps with this too, as does things like authentication (whic= h is often/usually used to prevent=C2=A0"Ooops" instead of malici= ous attacks).=C2=A0=C2=A0

It feels to me like the = concept of limited-domains is sometimes used like a magic incantation to av= oid having to answer some of the interoperability and security questions an= d concerns. Saying that a protocol should (or SHOULD or MUST) only be used = in a limited domain doesn't actually enforce that it will not leak. I a= lso do not think that it is reasonable that the protection / filtering to e= nforce limited=C2=A0domains should require the (potential) recipient to hav= e to change their filtering stance; I should not have to change my filterin= g policy to protect *my* network against *you* accidentally forgetting a fi= lter at the edge of your network.

If we do expect = potential recipients to have to update filters, there are 2 failure modes:<= /div>
1: the recipient=C2=A0doesn't (or misses=C2=A0an interface), = and bad things happen or
2: we end up in the "default-deny&q= uot; mode, where networks block all packets except those that they explicit= ly allow. This ossifies the network and makes deploying new things impossib= le.=C2=A0
Networks that experience breakage of the first type wil= l quickly move to the second option...=C2=A0

Ed= 9;s suggestion below ("All router=E2=80=99s ports should have RH type = 4 (SRH) filtered out by default.") is already heading down this path.<= /div>

The way I see this playing out is operators quickl= y moving along the lines of:=C2=A0
If I'm expected to filter = "RH type 4 (SRH)" on all of my external interfaces in case someon= e else=C2=A0decides to run SRH, what else should I filter? Clearly 5 and 6 = (CRH-16/32)... and 7, 8, ... 255.=C2=A0
I need to be ready *befor= e* you enable $insert_new_protocol_here, so the only sensible thing for me = to do is filter all RH/43. Oh, and I don't know what sort of new uses t= here might be for Hop-by-Hop that might affect me, so I should clearly just= filter all protocol 0 (perhaps in the future I might allow specific ones..= . maybe). HIP? I don't use that, but I might in the future, and I certa= inly=C2=A0don't have time to follow all of the new things being propose= d in the IETF/by vendors, so obviously I should filter that everywhere...
Actually, why am I bothering to write this long filter list? I'= ;ll just allow TCP and UDP, and call it done...

(W= hen I started writing the above I thought I would need to add a "Warni= ng: Hyperbole ahead" marker -- but I'm no longer sure that that= 9;s the case).


This path leads us t= o an ossified IPv6, and no ability to deploy new protocols. We need a solut= ion where the border of limited-domains is clear, and automatic - and where= the things touching the outside border don't need to actively protect = themselves from failures of the border protection,=C2=A0
W
<= div></no hats>

=C2=A0

=C2=A0

Now =E2=80=93 lets examine SRv6= for a second.

=C2=A0

In a scenario of Host A (A linu= x box) with address 2001:db8:1:1::10/64 =C2=A0=C2=A0utilizing a gateway of = 2001:db8:1:1::fefe =E2=80=93 packets from 2001:db8:1:1::10 flowing towards = that gateway would pass ingress filter checks based on BCP38 since the source address was legitimate, unless we explicitly filter= ed out where that packet could be destined for based on its DA (More on thi= s in a bit)

=C2=A0

Now, lets imagine for a second = that Host A gets compromised =E2=80=93 and an attack encapsulates a packet = that has an entirely different source address =E2=80=93 and whatever random= DA address inside an SRH.=C2=A0 That SRH has a SID list in it =E2=80=93 be it via a direct SID or via compression mechanisms, and = a DA towards the SID itself.=C2=A0 The packet then routes =E2=80=93 passing= the ingress checks =E2=80=93 and landing up at the router with the first S= ID.=C2=A0 Since this was the only SID in the list =E2=80=93 the packet oute= r SRH is removed =E2=80=93 and the inner packet is forwarded to the FIB =E2= =80=93 and you just bypassed BCP38.

=C2=A0

In a similar mechanism, if the = SRH states that the next protocol header is an IPv4 packet =E2=80=93 when t= he de-encapsulation happens at last SID =E2=80=93 the payload (the inner v4= packet) will then be forwarded via the FIB =E2=80=93 and off you go.

=C2=A0

Now, normally to protect agains= t this as stated =E2=80=93 an access list would be placed on the networks b= orders to prevent encapsulated packets and packets containing SID destinati= ons from entering the network.=C2=A0 However =E2=80=93 if we consider the above scenario where the attack is coming from a compromis= ed server inside the traditional borders =E2=80=93 we have a problem.=C2=A0= The application of access lists to every port containing a server is also = potentially unrealistic and unmaintainable (not to mention could potentially on certain devices overload the TCAMs)=

=C2=A0

We also have an even more poten= tially deadly issue =E2=80=93 and this is entirely theoretical at this poin= t since I haven=E2=80=99t had time to really investigate and test it with r= eal code.=C2=A0 Let us presume in the above that the same host A is compromised.=C2=A0 It encapsulates a packet with an SRH =E2=80= =93 the internal packet is an Ipv4 packet =E2=80=93 and its destined at a b= roadcast address of an IP subnet that is bound to the same network as the d= e-encapsulating router.=C2=A0 The source of the internal v4 packet is spoofed =E2=80=93 we=E2=80=99ve now managed to =E2=80=93 through= a use of the tunneling mechanism, effectively created a version of an old = tool called smurf =E2=80=93 in a manner that is going to be pretty hard to = trace.

=C2=A0

Another potential scenario =E2= =80=93 would be for an attacker in host A to jit some ebpf code =E2=80=93 t= hat matches =E2=80=93 modifies and re-encapsulates incoming return packets = and retransmits then. Each time applying the same SRH.=C2=A0 The inner packet could be pretty much anything =E2=80=93 so long as the internal DA = is set back to host A that is sending the packet.=C2=A0 The packet would th= en flow out as an SRH encapsulated packet, the outer header would get poppe= d, the inner packet would flow back towards the original compromised host, which would match it modify it re-encapsulate i= t and start the loop again.=C2=A0 Doing this with ebpf and a kernel jit =E2= =80=93 would be pretty difficult to spot if you didn=E2=80=99t know what yo= u are doing because you wouldn=E2=80=99t potentially see any obvious userland code.=C2=A0

=C2=A0

As a final thought =E2=80=93 co= nsider a hypervisor based system =E2=80=93 that has multiple VM=E2=80=99s o= n it =E2=80=93 and the filtering implications of all of the above =E2=80=93= and the filtering becomes even more difficult to maintain and more complex= .

=C2=A0

Again =E2=80=93 the filtering p= er every port that may contains a server or a desktop =E2=80=93 that may no= t be realistic =E2=80=93 especially when we could be running multiple ports= that are handing out source addresses via RA =E2=80=93 so =E2=80=93 how do we solve this =E2=80=93 or is this a major flaw in srv6 itself =E2=80=93 t= hat needs some other solution (give srv6 its own protocol code and acknowle= dge that it isn=E2=80=99t ipv6 at all, allowing for a =E2=80=9Cfail-closed= =E2=80=9D scenario maybe?)

=C2=A0

As an operator that runs extens= ive IPv6 =E2=80=93 I=E2=80=99d really like to hear thoughts and comments an= d potentially we can find a way to address these issues.

=C2=A0

Thanks

=C2=A0

Andrew

=C2=A0

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
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
--0000000000005bc60605cef4c708--