From nobody Tue Mar 2 06:45:25 2021 Return-Path: X-Original-To: sidrops@ietfa.amsl.com Delivered-To: sidrops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA833A1946 for ; Tue, 2 Mar 2021 06:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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=gmail.com 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 ch3iMPOIXvg5 for ; Tue, 2 Mar 2021 06:45:20 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 7D3B23A1950 for ; Tue, 2 Mar 2021 06:45:20 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id g8so16527747otk.4 for ; Tue, 02 Mar 2021 06:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MnRP2Sn+MVk05NTbcJfFJ9bpq672zYGHq5KKSZ9US74=; b=kkYnLRIarXaBjTy44tr6j9qHu+bLCNOKpQ9j77fqmL3tyrgNklE6m53H9KTLTaEv0/ jO2TssEucAZwor38HufmzVSCw55DJSi7C78Ohht7gQ8qE6IhoAIQPi7zIKZ3Z4iJI7W/ BijYx0P/dkzrHgul5X+1p6itoG7VlNLTgrtlYIntoqlxTymjb3ucszWcimrfOS6Qlx3b h5eEztDn0IsiV3TKauW8ZRsVK5A7me6diaFIXED91+ywRtZEmFeGYBrNCIGYKd0AwizX L7M4JsvIebU4HG6lFk+ank7u3/6NFv/eCH6/fSrsNJeuwWjtqSOY63+gL+uxKx5fP6PW 5bdg== 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=MnRP2Sn+MVk05NTbcJfFJ9bpq672zYGHq5KKSZ9US74=; b=D4CBLmAfs6tDb2AICOsB3tRSQuiCBKbzC9zpUsnmsyGnESnB8neu8YP3C/MuCYN3bR jrWuGnPAOTINRyEVjW/xlwlBNjY5PkInJTsAO3ffqNCXsWiPUT/M4fNfCHHUi1RMDKJ5 pLV5fuBD1Z+1LIZ8rvLb79/SdTsjKjkhXs4DGOxHlHXhagimlr8sc6VxQI51+f17tPPd akr603mgvcBUfLhsKFLvjxSiatNeuVDfTE+47D5+fqUPdfFsbFeVz9zUr/WvpX3ttFdL p/0Ht47EdNhwAtdYVxpUJZgjXrL3IBQfSic6ALVgN3dR3yGRieqEeTnRQ1eoWtiFaCMN jPkw== X-Gm-Message-State: AOAM531N9wWcu4+xq30G9iY2sAdvYCsZDV2bdEyAL14zU+TjaIcQn7iJ sQpcetd53d6jDgVaEBDsUiDCkI62CvWiG+yazc8= X-Google-Smtp-Source: ABdhPJwIo8hv3fd3Yl8QuPAGbvrhrWwyZ8kbrQG6jv9CTymsPRZUDbTMj4b1ruGPqL2cEta5sGawE1+7omrzhsPn+HY= X-Received: by 2002:a9d:76cf:: with SMTP id p15mr17402015otl.348.1614696319315; Tue, 02 Mar 2021 06:45:19 -0800 (PST) MIME-Version: 1.0 References: <20210223114202.uvfpmtz7jf52jvao@benm-laptop> In-Reply-To: From: Douglas Fischer Date: Tue, 2 Mar 2021 11:45:08 -0300 Message-ID: To: Job Snijders Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="00000000000088725a05bc8ec8ca" Archived-At: Subject: Re: [Sidrops] Improvements in RPKI ensuring backward compatibility - Would be possible? X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2021 14:45:25 -0000 --00000000000088725a05bc8ec8ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Job! First of all, thank you for your answer! I am curious to see how this will be implemented in Bird and OpenBGPD. (Maybe I'll get willing to adapt something for the FRR.) I will insist a bit (sorry if I'm pushing too much) on the question of making these propositions in order to guarantee backward compatibility. About the ROAs data structure extension --------------------------------------- As far as I can imagine (this would deserve research) 90% of current ROAs should not be valid for more than 12 months. Maybe 8% valid for up to 24 months. And I don't know if there are ROAs with validities that are greater than that. So it would not be incorrect to say that in the event of an extension of the ROA data model to include the minimum length, the transition period could be considered "short". I haven't researched much about the current ROA data structure yet, but I imagine that the PKI model includes version markers. Which would mean that an extra field could be added and considered only from a specific version. If this is true (I will still study and confirm), would be possible to define that "if the ROA is of the version with no minimum length, the minimum length will be considered the same as the prefix." during the transition. About the extension of the status of the Route in relation to the RPKI (in relation to the RTR) ---------------------------------------------------------------------------= -------------------- As I mentioned in the initial email (from the NLNetLabs list), the idea is to maintain the Macro statuses already contemplated by the RTR (Valid, Invalid, Unknown) precisely to maintain backward compatibility. But add complementary statuses(especially on Invalid). With that same old RTR-clients would be compatible to consult new RTR-servers, and new RTR-clients would be compatible to consult old RTR-servers. In both cases maintaining the current minimum response level. Em ter., 2 de mar. de 2021 =C3=A0s 10:14, Job Snijders esc= reveu: > Dear Douglas, > > The negative side: I suspect there will not be much interest in changing > the Route Origin Authorizations profile, because that profile is already > widely used and has a specific meaning which has been implemented in > many many software systems. It is not possible at this stage of the game > to change ROA data structure or the meaning of ROAs! > > The GOOD news: > > Work in under way to harmonize RPKI & BGP blackholing. The IETF's draft > submission window currently is closed, but as soon as it opens, I will > upload a document detailing a possible way forward. (1 or 2 weeks from > now) > > The proposal envisions a mechanism which will be easy to deploy on BIRD > or OpenBGPD and other modern BGP implementations. > > Stay tuned! > > Kind regards, > > Job > > > On Mon, Mar 01, 2021 at 08:51:10AM -0300, Douglas Fischer wrote: > > I recently sent this email(below) to the NLNetLabs RPKI list. > > https://lists.nlnetlabs.nl/pipermail/rpki/2021-February/000261.html > > > > And I was recommended to bring this topic to sidrops. > > > > > > I am not yet familiar with the M.O. of this community, so I apologize a= nd > > accept guidance for any inappropriate behavior. > > > > I am concerned to keep the healthy use of RTBH viable... > > I know that this is not the best mechanism to solve problems with DDoS > and > > similar. > > But in practice, it ends up being the most cost-effective tool for the > > operator of the ASN itself that is being targeted by what I call "silly > > attacks" to react and evade those attacks. > > > > The purpose of this email is to present two possibilities that I have > been > > imagining for some time as good measures for RPKI. > > > > Note: As I know that I am locked in the point of view of those who only > see > > the positive side of an idea ... I am open to seeing the negative side = of > > these ideas. > > > > ----- > > 1 - Increase the levels, officially in the protocol, the status of a > route > > based on the RPKI, Specially of Invalid Status. > > ----- > > In the email below, this concept is reasonably well described. > > I kindly ask you to read this detail below. > > > > This is already possible to implement today if the protocol is "sliced"= a > > little, but it needs to be done using specific ROA validator engines, a= nd > > it needs to be done on a host that allows you to execute specific code, > > which prevents this from being natively implemented and standard router= s > on > > the market. > > > > The idea is to give the ASN operator the autonomy to decide (on > > routing-filter policies) what to do with some route, based on the > detailed > > RPKI status of that route. > > > > > > P.S .: I have observed that other initiatives are inclined to go the sa= me > > way of further analyzing the status of the Route based on ROA. Unless > > mistaken, there are discussions about this in projects involving some > > Route-Server used by several IXPs to improve Police-Filtering of RTBH. > > > > ----- > > 2 - Add the possibility of using the "minimum prefix length" attribute = in > > RPKI ROAs. > > ----- > > With that, I believe that the reality of the routes generated by the AS= Ns > > would be better represented. In addition to allowing ROAs exclusively > > created for RTBH and the like to be created. > > > > Ex.1: An organization with an IPv4 / 16 block will rarely advertise thi= s > > block only with a single route. Whether for geographic reasons or for > > routing strategy, it will probably advertise this in / 18-20 block. > > Ex.2 .: This same organization may want to tell the world that Routes > > originated by its own ASN, or by ASNs of scrubing companies, of the > prefix > > of this / 16 with the mask "LE 32" "GE 32" are valid. > > > > > > > > Thanks in advance for your patience and comprehension. > > > > -- > > Douglas Fernando Fischer > > Eng=C2=BA de Controle e Automa=C3=A7=C3=A3o > > > > > > Em ter., 23 de fev. de 2021 =C3=A0s 08:42, Ben Maddison > > > escreveu: > > > > > Hi Douglas, > > > > > > On 02/23, Douglas Fischer via RPKI wrote: > > > > I don't know if this is the best forum to discuss this ... > > > > If not, I apologize. > > > > > > > The SIDROPS WG list would probably be a better bet, but we can start > > > here! > > > > > > > So far I was not aware of this draft, which already has 6 versions, > and > > > is > > > > heading towards the final version. > > > > > > > > https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06 > > > > > > > > As far as I could understand, the main reason for proposing this > draft is > > > > to enable a safe and fast way to make the security of the RPKI orig= in > > > > validation also include the cases of RTBH ads that are generally of > > > unique > > > > IPs (/ 32 or / 128 ). > > > > > > > I think that you have misunderstood the intention of the draft, and i= n > > > particular the latest version (which made substantial changes to the > > > section that deals with RTBH). > > > > > > The point of the draft is to call attention to that fact that creatin= g > > > ROAs which permit the origination of more-specific prefixes than are > > > usually present in the DFZ creates an attack vector that can be > > > exploited by hijackers. > > > > > > E.g. if I create a ROA: > > > 41.78.188.0/22, maxLength: 24, asID: 37271 > > > But then only originate: > > > 41.78.188.0/22, AS_PATH 37271 > > > > > > Then an attacker can announce: > > > 41.78.191.0/24, AS_PATH 666_37271 > > > > > > And will likely succeed in becoming the best path. > > > > > > It was observed that this issue is particularly present in ROAs where > > > the issuer had made use of the maxLength field - hence the title of t= he > > > draft. > > > > > > The draft also points out that because RTBH routes are typically for > > > much longer prefixes, operators might be tempted to use maxLength to > > > allow those routes to be ROV valid, and that doing so is a bad idea, > > > because it creates the above attack vector. > > > > > > It doesn't try to propose any solution to the real issue of how > ROV/RTBH > > > should co-exist beyond that. > > > > > > If you think that any of the above could be made clearer in the curre= nt > > > text, please feel free to propose changes. > > > > > > > Honestly, so far I am undecided as to whether this is the best > > > methodology > > > > for such a solution. > > > > > > > > Until now I was adopting (especially for route-servers) the > methodology > > > of > > > > further analyzing the possible status of RPKI. > > > > - Valid -> complements do not fit > > > > - Unknown -> complements do not fit > > > > - Invalid -> by previous ROA Date > > > > - Invalid -> by Later ROA Date > > > > - Invalid -> by ASN of Origin > > > > - Invalid -> for less specific mask > > > > - Invalid -> by more specific mask > > > > > > > > Thus, in the route filtering tests received against Blackhole I was > using > > > > the following logic: > > > > > > > > If (is into AS-SET My-Customer) and \ > > > > (has Black-Hole-Community) and \ > > > > ((is IPv4 and is /32) or (is IPv6 and is /128)) and \ > > > > ((is RPKI Valid) or (is RPKI unknow) or (is RPKI invalid by mas > more > > > > specific)) then \ > > > > accept as Blackhole... > > > > > > > > P.S.: This is a very summarized way to express the logic... I had t= o > do > > > > some gymnastics to implement it... Converting RPKI JSONs belonging = to > > > each > > > > AS-SET to Prefix-lists. > > > > > > > That algorithm looks mostly sensible, and roughly similar to how we > > > (AS37271) are planning to implement this in the next couple of months= . > > > > > > However, I'd like to stress that is *not* proposed in > > > draft-ietf-sidrops-rpkimaxlen. > > > Doing that would require an update to RFC6811, and I would argue > > > strongly against it! > > > > > > Cheers, > > > > > > Ben > > > > > > > > > -- > > Douglas Fernando Fischer > > Eng=C2=BA de Controle e Automa=C3=A7=C3=A3o > > > _______________________________________________ > > Sidrops mailing list > > Sidrops@ietf.org > > https://www.ietf.org/mailman/listinfo/sidrops > > --=20 Douglas Fernando Fischer Eng=C2=BA de Controle e Automa=C3=A7=C3=A3o --00000000000088725a05bc8ec8ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Job!

First of all, thank you fo= r your answer!
I am curious to see how this will be implemented in Bird = and OpenBGPD.
(Maybe I'll get willing to adapt something for the FRR= .)



I will insist a bit (sorry if I'm pushing too much) o= n the question of making these propositions in order to guarantee backward = compatibility.


About the ROAs data structure extension
------= ---------------------------------
As far as I can imagine (this would de= serve research) 90% of current ROAs should not be valid for more than 12 mo= nths. Maybe 8% valid for up to 24 months. And I don't know if there are= ROAs with validities that are greater than that.
So it would not be inc= orrect to say that in the event of an extension of the ROA data model to in= clude the minimum length, the transition period could be considered "s= hort".

I haven't researched much about the current ROA data= structure yet, but I imagine that the PKI model includes version markers. = Which would mean that an extra field could be added and considered only fro= m a specific version.
If this is true (I will still study and confirm), = would be possible to define that "if the ROA is of the version with no= minimum length, the minimum length will=C2=A0be considered the same as the= prefix." during the transition.


About the extension of the= status of the Route in relation to the RPKI (in relation to the RTR)
--= ---------------------------------------------------------------------------= ------------------=C2=A0 =C2=A0
As I mentioned in the initial email (fro= m the NLNetLabs list), the idea is to maintain the Macro statuses already c= ontemplated by the RTR (Valid, Invalid, Unknown) precisely to maintain back= ward compatibility.
But add complementary statuses(espec= ially on Invalid).
With that same old RTR-clients would be compatible to= consult new RTR-servers, and new RTR-clients would be compatible to consul= t old RTR-servers. In both cases maintaining the current minimum response l= evel.



=
Em ter., 2= de mar. de 2021 =C3=A0s 10:14, Job Snijders <job@fastly.com> escreveu:
Dear Douglas,

The negative side: I suspect there will not be much interest in changing the Route Origin Authorizations profile, because that profile is already widely used and has a specific meaning which has been implemented in
many many software systems. It is not possible at this stage of the game to change ROA data structure or the meaning of ROAs!

The GOOD news:

Work in under way to harmonize RPKI & BGP blackholing. The IETF's d= raft
submission window currently is closed, but as soon as it opens, I will
upload a document detailing a possible way forward. (1 or 2 weeks from
now)

The proposal envisions a mechanism which will be easy to deploy on BIRD
or OpenBGPD and other modern BGP implementations.

Stay tuned!

Kind regards,

Job


On Mon, Mar 01, 2021 at 08:51:10AM -0300, Douglas Fischer wrote:
> I recently sent this email(below) to the NLNetLabs RPKI list.
> https://lists.nlnetlabs.nl/p= ipermail/rpki/2021-February/000261.html
>
> And I was recommended to bring this topic to sidrops.
>
>
> I am not yet familiar with the M.O. of this community, so I apologize = and
> accept guidance for any inappropriate behavior.
>
> I am concerned to keep the healthy use of RTBH viable...
> I know that this is not the best mechanism to solve problems with DDoS= and
> similar.
> But in practice, it ends up being the most cost-effective tool for the=
> operator of the ASN itself that is being targeted by what I call "= ;silly
> attacks" to react and evade those attacks.
>
> The purpose of this email is to present two possibilities that I have = been
> imagining for some time as good measures for RPKI.
>
> Note: As I know that I am locked in the point of view of those who onl= y see
> the positive side of an idea ... I am open to seeing the negative side= of
> these ideas.
>
> -----
> 1 - Increase the levels, officially in the protocol, the status of a r= oute
> based on the RPKI, Specially of Invalid Status.
> -----
> In the email below, this concept is reasonably well described.
> I kindly ask you to read this detail below.
>
> This is already possible to implement today if the protocol is "s= liced" a
> little, but it needs to be done using specific ROA validator engines, = and
> it needs to be done on a host that allows you to execute specific code= ,
> which prevents this from being natively implemented and standard route= rs on
> the market.
>
> The idea is to give the ASN operator the autonomy to decide (on
> routing-filter policies) what to do with some route, based on the deta= iled
> RPKI status of that route.
>
>
> P.S .: I have observed that other initiatives are inclined to go the s= ame
> way of further analyzing the status of the Route based on ROA. Unless<= br> > mistaken, there are discussions about this in projects involving some<= br> > Route-Server used by several IXPs to improve Police-Filtering of RTBH.=
>
> -----
> 2 - Add the possibility of using the "minimum prefix length"= attribute in
> RPKI ROAs.
> -----
> With that, I believe that the reality of the routes generated by the A= SNs
> would be better represented. In addition to allowing ROAs exclusively<= br> > created for RTBH and the like to be created.
>
> Ex.1: An organization with an IPv4 / 16 block will rarely advertise th= is
> block only with a single route. Whether for geographic reasons or for<= br> > routing strategy, it will probably advertise this in / 18-20 block. > Ex.2 .: This same organization may want to tell the world that Routes<= br> > originated by its own ASN, or by ASNs of scrubing companies, of the pr= efix
> of this / 16 with the mask "LE 32" "GE 32" are val= id.
>
>
>
> Thanks in advance for your patience and comprehension.
>
> --
> Douglas Fernando Fischer
> Eng=C2=BA de Controle e Automa=C3=A7=C3=A3o
>
>
> Em ter., 23 de fev. de 2021 =C3=A0s 08:42, Ben Maddison <benm@worko= nline.africa>
> escreveu:
>
> > Hi Douglas,
> >
> > On 02/23, Douglas Fischer via RPKI wrote:
> > > I don't know if this is the best forum to discuss this .= ..
> > > If not, I apologize.
> > >
> > The SIDROPS WG list would probably be a better bet, but we can st= art
> > here!
> >
> > > So far I was not aware of this draft, which already has 6 ve= rsions, and
> > is
> > > heading towards the final version.
> > >
> > > https://tools.ietf.org/ht= ml/draft-ietf-sidrops-rpkimaxlen-06
> > >
> > > As far as I could understand, the main reason for proposing = this draft is
> > > to enable a safe and fast way to make the security of the RP= KI origin
> > > validation also include the cases of RTBH ads that are gener= ally of
> > unique
> > > IPs (/ 32 or / 128 ).
> > >
> > I think that you have misunderstood the intention of the draft, a= nd in
> > particular the latest version (which made substantial changes to = the
> > section that deals with RTBH).
> >
> > The point of the draft is to call attention to that fact that cre= ating
> > ROAs which permit the origination of more-specific prefixes than = are
> > usually present in the DFZ creates an attack vector that can be > > exploited by hijackers.
> >
> > E.g. if I create a ROA:
> >=C2=A0 =C2=A0 =C2=A041.78.188.0/22, maxLength: 24, asID: 37271
> > But then only originate:
> >=C2=A0 =C2=A0 =C2=A041.78.188.0/22, AS_PATH 37271
> >
> > Then an attacker can announce:
> >=C2=A0 =C2=A0 =C2=A041.78.191.0/24, AS_PATH 666_37271
> >
> > And will likely succeed in becoming the best path.
> >
> > It was observed that this issue is particularly present in ROAs w= here
> > the issuer had made use of the maxLength field - hence the title = of the
> > draft.
> >
> > The draft also points out that because RTBH routes are typically = for
> > much longer prefixes, operators might be tempted to use maxLength= to
> > allow those routes to be ROV valid, and that doing so is a bad id= ea,
> > because it creates the above attack vector.
> >
> > It doesn't try to propose any solution to the real issue of h= ow ROV/RTBH
> > should co-exist beyond that.
> >
> > If you think that any of the above could be made clearer in the c= urrent
> > text, please feel free to propose changes.
> >
> > > Honestly, so far I am undecided as to whether this is the be= st
> > methodology
> > > for such a solution.
> > >
> > > Until now I was adopting (especially for route-servers) the = methodology
> > of
> > > further analyzing the possible status of RPKI.
> > > - Valid -> complements do not fit
> > > - Unknown -> complements do not fit
> > > - Invalid -> by previous ROA Date
> > > - Invalid -> by Later ROA Date
> > > - Invalid -> by ASN of Origin
> > > - Invalid -> for less specific mask
> > > - Invalid -> by more specific mask
> > >
> > > Thus, in the route filtering tests received against Blackhol= e I was using
> > > the following logic:
> > >
> > > If (is into AS-SET My-Customer) and \
> > >=C2=A0 =C2=A0 (has Black-Hole-Community) and \
> > >=C2=A0 =C2=A0 ((is IPv4 and is /32) or (is IPv6 and is /128))= and \
> > >=C2=A0 =C2=A0 ((is RPKI Valid) or (is RPKI unknow) or (is RPK= I invalid by mas more
> > > specific)) then \
> > >=C2=A0 =C2=A0 accept as Blackhole...
> > >
> > > P.S.: This is a very summarized way to express the logic... = I had to do
> > > some gymnastics to implement it... Converting RPKI JSONs bel= onging to
> > each
> > > AS-SET to Prefix-lists.
> > >
> > That algorithm looks mostly sensible, and roughly similar to how = we
> > (AS37271) are planning to implement this in the next couple of mo= nths.
> >
> > However, I'd like to stress that is *not* proposed in
> > draft-ietf-sidrops-rpkimaxlen.
> > Doing that would require an update to RFC6811, and I would argue<= br> > > strongly against it!
> >
> > Cheers,
> >
> > Ben
> >
>
>
> --
> Douglas Fernando Fischer
> Eng=C2=BA de Controle e Automa=C3=A7=C3=A3o

> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org=
> https://www.ietf.org/mailman/listinfo/sidrops<= br>


--
Douglas Fernando Fischer
Eng=C2=BA de Controle e Automa=C3=A7=C3= =A3o
--00000000000088725a05bc8ec8ca--