From nobody Sun Sep 2 15:20:02 2018 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 E72C1130DF3; Sun, 2 Sep 2018 15:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 EdqzGtLi1tIv; Sun, 2 Sep 2018 15:19:50 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 9713F130DF1; Sun, 2 Sep 2018 15:19:47 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fwaia-0006yu-Hb; Mon, 03 Sep 2018 00:19:40 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::91]) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fwaiZ-0002HO-9f; Mon, 03 Sep 2018 00:19:39 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_0ADA1384-BD8F-414B-9767-77954F063C1F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Oleg Muravskiy In-Reply-To: <153547412129.23827.3324575091222487462.idtracker@ietfa.amsl.com> Date: Mon, 3 Sep 2018 00:19:38 +0200 Cc: The IESG , draft-ietf-sidrops-rpki-tree-validation@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Message-Id: <4A92D060-389A-4104-A7CF-49984773596B@ripe.net> References: <153547412129.23827.3324575091222487462.idtracker@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b7452a006025f41fd5c881469cffb812ef4 Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.27 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: Sun, 02 Sep 2018 22:19:53 -0000 --Apple-Mail=_0ADA1384-BD8F-414B-9767-77954F063C1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Benjamin, Thanks for your comments. I am updating the draft, please see my inline = comments below: > On 28 Aug 2018, at 18:35, Benjamin Kaduk wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This document is Informational, so I will make my comments = non-blocking, > but I think that the security considerations could be improved. It > currently does a good job talking about cases where the procedure can > receive inconsistent inputs (and how it behaves in the face of those > inputs), as well as some other considerations, and this is great! I = think > that the discussion could be more powerful if it also considered how = those > inconsistent inputs could be produced, in particular which = capabilities an > attacker could have. There seem to be roughly three classes of actors = for > active attacks -- an attacker in the network could modify the = transferred > content (including number of files and directory layout) over = unecrypteed > rsync or http, an attacker that compromises the webserver's = certificate > (or obtains a fraudulent one) could do the same over encrypted https, = and > an attacker that compromises the TA signing key could produce > fake-but-"valid" manifests, CRLs, etc.. (Is there more that could be = done > with a compromised non-TA CA? The potential hazards to this algorithm > don't seem to be noticably distinct, though.) Some consumers may be > willing to trust in the TA's integrity or even the Web PKI and not = worry > about those risks. Though there is always risk of accidental error, = of > course, and the current coverage in this document seems adequate for = that > risk. In the Security Considerations we tried to describe issues specific to = our implementation. What you suggest seems to be a general discussion of vulnerabilities in = the RPKI repository architecture that is defined by current standards. I = agree that it is missing in the current set of RFCs and it would be = great to have it, but on the other hand I do not think it should be done = it this document. It would also require another round of going through = the WG discussion, I believe. So I left this section as is. > Some additional section-by-section comments follow. >=20 > Section 3.1 >=20 > The key properties needed of cryptographic hash functions are either > "collision resistance" or "second preimage resistance", depending on > whether the attacker gets to pick both hash inputs (the first case) or = only > one of them (the second). Which one is needed here would probably = depend > on whether the CA/issuer is trusted to not be an attacker or not, but > regardless, please use the more detailed terminology. I=E2=80=99m going for the =E2=80=9Ccollision resistance properties=E2=80=9D= in that paragraph. But also note that it isn=E2=80=99t only about attacks on the repository = objects: if there are legitimate objects anywhere in fetched = repositories that produce the same hashes, they will collide in our = implementation. > Section 3.2 >=20 > [...], or use all objects whose AKI extension > matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of > [RFC5280]) of a CA certificate. >=20 > "all objects" as discovered within what scope? Essentially these are all objects known to a validator at the time the = comparison is performed. I=E2=80=99m changing the draft to read =E2=80=9Call known repository = objects=E2=80=9D. > Section 4.2 >=20 > Please expand SIA on first usage. ACK > In bullet point 1, it might help the uninitiated reader to say = something > after "and pass it to the object fetcher" to note that "the fetcher = will > then fetch all objects available from that repository=E2=80=9D. ACK > In bullet point 3, please be more clear about which manifest is "this > manifest object" that is used to continue validation processing. ACK > 4. Perform manifest entries discovery and validation as described = in > Section 4.2.2. >=20 > nit: "manifest entry discovery" (singular "entry=E2=80=9D) The manifest contains an entry per object in the publication point, so = there are at least 2 entries =E2=80=93 for a CA cert and a manifest. I guess plural =E2=80=9Centries=E2=80=9D is appropriate here. > (Note that this implementation uses the operator configuration = to > decide which algorithm to use for path validation. It applies > selected algorithm to all resource certificates, rather than >=20 > nit: "the selected algorithm=E2=80=9D ACK > Please expand ROA on first usage. ACK > Section 5.1.1, 5.1.2 >=20 > The syntactic verification performed here is done on what should be > considered "untrusted input", which means that the verification code = needs > to be written in a robust manner. (Given the historical recurrences = of, > e.g., ASN.1 decoder security vulnerabilities, we probably need to > explicitly state this in the security considerations.) Well, I could say that the validation =E2=80=9Cis written and performed = in a robust manner=E2=80=9D, but I do not see how this will improve the = content... > Section 9.1 >=20 > If I understand correctly, RFC 6485 allows for (and predicts the need = for) > hash agility in the file hash algorithm. In this case, it would = probably > be appropriate to say something about how "the security of the system = as a > whole is limited to that of the weakest hash function allowed by = consumers, > but the hash agility provided for by RFC 6485 allows new (stronger) = hashes > to be introduced and old hash functions phased out before they are > critically broken=E2=80=9D. The sentence you propose describes the current situation of the RPKI in = general, it is not specific to our implementation, or to RPKI tree = validation.=20 RFC 6485 said: The recommended procedures to implement such a transition of key sizes and algorithms is not specified in this document. As such, our validator does not support any other algorithms for keys = and hashes. By now, however, RFC 6485 has been obsoleted by 7935, which refers to = RFC 6916 for details of algorithm agility. I=E2=80=99m adding a sentence that agility is not supported in our = implementation. > Section 9.2 >=20 > In case of a mismatch described above this implementation will not > exclude an object from further validation merely because it's actual >=20 > nit: "its" (no apostrophe) ACK > Section 9.3 >=20 > nit: Which behavior is allowed-but-not-required -- a CA signing things = not > listed in the manifest, or an RP ignoring things not listed in the > manifest? I suggest "This RP behavior is allowed [...]=E2=80=9D. ACK > Section 9.4 >=20 > This kind of behavior would be seen as an unacceptable vulnerability = in a > standards-track protocol, though since this document is only = informational > it does not block publication. =46rom the RP perspective it is not possible to know whether the object = it received from the remote repository is genuine or tampered with. = Current standards require that invalid objects must not be used for = validation, and this is what our implementation does. There is no = requirement to keep and use an =E2=80=9Cold=E2=80=9D object (whatever = that might be) if the =E2=80=9Cnew=E2=80=9D one is not valid. > Section 9.5 >=20 > It might be useful to reference Section 5.1.1 and how we sometimes = fetch > the entire repository contents, not limited by a manifest listing. ACK Cheers, Oleg= --Apple-Mail=_0ADA1384-BD8F-414B-9767-77954F063C1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Benjamin,

Thanks for = your comments. I am updating the draft, please see my inline comments = below:

On 28 Aug 2018, at 18:35, Benjamin Kaduk = <kaduk@mit.edu> = wrote:
---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

This document is Informational, so = I will make my comments non-blocking,
but I think that the = security considerations could be improved.  It
currently does a good job talking about cases where the = procedure can
receive inconsistent inputs (and how it = behaves in the face of those
inputs), as well as some = other considerations, and this is great!  I think
that = the discussion could be more powerful if it also considered how those
inconsistent inputs could be produced, in particular which = capabilities an
attacker could have.  There seem to = be roughly three classes of actors for
active attacks -- = an attacker in the network could modify the transferred
content (including number of files and directory layout) over = unecrypteed
rsync or http, an attacker that compromises = the webserver's certificate
(or obtains a fraudulent one) = could do the same over encrypted https, and
an attacker = that compromises the TA signing key could produce
fake-but-"valid" manifests, CRLs, etc..  (Is there more = that could be done
with a compromised non-TA CA?  The = potential hazards to this algorithm
don't seem to be = noticably distinct, though.)  Some consumers may be
willing to trust in the TA's integrity or even the Web PKI = and not worry
about those risks.  Though there is = always risk of accidental error, of
course, and the = current coverage in this document seems adequate for that
risk.

In the Security Considerations we tried to = describe issues specific to our implementation.
What you = suggest seems to be a general discussion of vulnerabilities in the RPKI = repository architecture that is defined by current standards. I agree = that it is missing in the current set of RFCs and it would be great to = have it, but on the other hand I do not think it should be done it this = document. It would also require another round of going through the WG = discussion, I believe. So I left this section as is.

Some additional section-by-section comments follow.

Section 3.1

The = key properties needed of cryptographic hash functions are either
"collision resistance" or "second preimage resistance", = depending on
whether the attacker gets to pick both hash = inputs (the first case) or only
one of them (the second). =  Which one is needed here would probably depend
on = whether the CA/issuer is trusted to not be an attacker or not, but
regardless, please use the more detailed terminology.

I=E2=80= =99m going for the =E2=80=9Ccollision resistance properties=E2=80=9D in = that paragraph.
But also note that it isn=E2=80=99t only about = attacks on the repository objects: if there are legitimate objects = anywhere in fetched repositories that produce the same hashes, they will = collide in our implementation.

Section 3.2

  [...], or use all objects whose = AKI extension
  matches the Subject Key = Identifier (SKI) extension (Section 4.2.1 of
=   [RFC5280]) of a CA certificate.

"all objects" as discovered within what scope?

Essentially these are all objects known to a = validator at the time the comparison is performed.
I=E2=80=99m = changing the draft to read =E2=80=9Call known repository = objects=E2=80=9D.

Section 4.2

Please expand SIA on first usage.

ACK

In bullet point 1, it might = help the uninitiated reader to say something
after "and = pass it to the object fetcher" to note that "the fetcher will
then fetch all objects available from that repository=E2=80=9D.=

ACK

In bullet point 3, please be = more clear about which manifest is "this
manifest object" = that is used to continue validation processing.

ACK

  4.  Perform = manifest entries discovery and validation as described in
=       Section 4.2.2.

nit: "manifest entry discovery" (singular "entry=E2=80=9D)

The = manifest contains an entry per object in the publication point, so there = are at least 2 entries =E2=80=93 for a CA cert and a = manifest.
I guess plural =E2=80=9Centries=E2=80=9D is = appropriate here.

      (Note that this = implementation uses the operator configuration to
=       decide which algorithm to use for = path validation.  It applies
=       selected algorithm to all resource = certificates, rather than

nit: "the selected = algorithm=E2=80=9D

ACK

Please expand ROA on first = usage.

ACK

Section 5.1.1, 5.1.2

The syntactic verification performed here is = done on what should be
considered "untrusted input", which = means that the verification code needs
to be written in a = robust manner.  (Given the historical recurrences of,
e.g., ASN.1 decoder security vulnerabilities, we probably = need to
explicitly state this in the security = considerations.)

Well, I could say that the validation =E2=80=9Cis = written and performed in a robust manner=E2=80=9D, but I do not see how = this will improve the content...

Section 9.1

If I understand correctly, RFC 6485 allows for = (and predicts the need for)
hash agility in the file hash = algorithm.  In this case, it would probably
be = appropriate to say something about how "the security of the system as = a
whole is limited to that of the weakest hash function = allowed by consumers,
but the hash agility provided for by = RFC 6485 allows new (stronger) hashes
to be introduced and = old hash functions phased out before they are
critically = broken=E2=80=9D.

The sentence you propose describes the current = situation of the RPKI in general, it is not specific to our = implementation, or to RPKI tree validation. 

RFC 6485 said:
   The = recommended procedures to implement such a
   transition of key sizes and algorithms is not =
specified in this
   document.

As = such, our validator does not support any other algorithms for keys and = hashes.
By now, however, RFC 6485 has been = obsoleted by 7935, which refers to RFC 6916 for details of algorithm = agility.

I=E2=80= =99m adding a sentence that agility is not supported in our = implementation.

Section 9.2

  In case of a mismatch described above this = implementation will not
  exclude an object = from further validation merely because it's actual

nit: "its" (no apostrophe)

ACK

Section 9.3

nit: Which behavior is allowed-but-not-required -- a CA = signing things not
listed in the manifest, or an RP = ignoring things not listed in the
manifest?  I = suggest "This RP behavior is allowed [...]=E2=80=9D.

ACK

Section 9.4

This kind of behavior would be seen as an unacceptable = vulnerability in a
standards-track protocol, though since = this document is only informational
it does not block = publication.

=46rom the RP perspective it is not possible to = know whether the object it received from the remote repository is = genuine or tampered with. Current standards require that invalid objects = must not be used for validation, and this is what our implementation = does. There is no requirement to keep and use an =E2=80=9Cold=E2=80=9D = object (whatever that might be) if the =E2=80=9Cnew=E2=80=9D one is not = valid.


Section 9.5

It might be useful to reference Section 5.1.1 = and how we sometimes fetch
the entire repository contents, = not limited by a manifest listing.

ACK


Cheers,
Oleg
= --Apple-Mail=_0ADA1384-BD8F-414B-9767-77954F063C1F-- From nobody Tue Sep 4 08:57:45 2018 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 26D93130F33 for ; Tue, 4 Sep 2018 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6cIgwURd15RH for ; Tue, 4 Sep 2018 08:57:42 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 10864129C6B for ; Tue, 4 Sep 2018 08:57:42 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id g18-v6so3286531uam.6 for ; Tue, 04 Sep 2018 08:57:42 -0700 (PDT) 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=KzHYRQ0DQPWQ4wTHDZasxE3eoRdwrsEZRPl9m6LYpSU=; b=VZeROJ1UsJkljqa7XkOO8JTEOz1+vkcqbabeLIjp2RFF9V6bA///OyJC4y2kpDw2Lk m78dQk0iN9dBWsq/8laoXccQDg8ONTJS+ur73f/iIY6ErKZEJpQFGy63YSFaSMtVtmBe kTyGq9//CFdUNzcy8VKRM0fXPaPuGWJwtiNwZV1E5GVNLpwmrJg3WH81TMelFbBspoa4 XPS+xglTQ/7tjW78wczT8hZkXi1roFfX1lIci6JJUqD6BoDXwvN6L5o9SPvwFXJCjJzf Av003RogwP+QQgp85Yz20JcVTg7l6HYuxT30WkkCkNZgmP6bIJvETOBjAggh3dG4N4Wc LMZQ== 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=KzHYRQ0DQPWQ4wTHDZasxE3eoRdwrsEZRPl9m6LYpSU=; b=YC1x3c7UYoedXeIj1yhdU2GztReXMOY9ycnJkdD0/yU01ZJUc7PAkL6wu/fZX9euAj +C1MHAtujRq35vZmxGA035MUkGYeF7wEANBY1r8xqUTKkq0A8OK9ojUHzmzqSOygXo58 /A5TrVndqrm/0Bsl9ucx9vE7S/SCgSnI9cVqekGFkrfIinAP/K7oRZTThrP2aakgUy+B 4X+NHl+FhMhl/zjzAPRP0XQqU4aCaQ+NaOWY07N5PUaRSZwadubHyONrz2ZKcvo6ZgyA ss86gd08wmdvv1RFiHvrfbSEwl9Bm54x5dqnuJXJRqtDt2ms71nyUoYhkYBae6wX8xs0 rvOQ== X-Gm-Message-State: APzg51A74ya89vn0tD25joFTpkar/9lSQvnqTlEklWtIkqlv1Mfa6nb+ Plnwk9ci8NP1ox2g8PnXG4chgE82L2gxWYa80BY= X-Google-Smtp-Source: ANB0Vdbne0Qx+60unu+CDBq+BgwX4zHi/lsqQ9yQFTeQdh8we+RHT/jwd+rPyVaOPb9+myoi7QPT8FtDoer9Mveq+f8= X-Received: by 2002:ab0:6510:: with SMTP id w16-v6mr11036520uam.139.1536076660814; Tue, 04 Sep 2018 08:57:40 -0700 (PDT) MIME-Version: 1.0 References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> In-Reply-To: <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> From: Christopher Morrow Date: Tue, 4 Sep 2018 11:57:29 -0400 Message-ID: To: daniel.kopp@de-cix.net Cc: sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000b73b0f05750db7c7" Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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, 04 Sep 2018 15:57:44 -0000 --000000000000b73b0f05750db7c7 Content-Type: text/plain; charset="UTF-8" I think restating an earlier conversation about this draft (which I think was the rpki-light draft name) is useful: "The draft aims to provide the ability for a third-party (IXP) to validate routes for me, because I can't do that myself" The reasons why 'I' may not be able to do the validation are perhaps shifting in time though, which I think should be acknowledged in this conversation that's progressed since the original draft was proposed. On Fri, Aug 24, 2018 at 10:33 AM Daniel Kopp wrote: > > The initial idea for the draft came from network operators at IXPs. > It's worth noting that -ops groups in the IETF are supposed to gather requirements from actual operators and coalesce these into change proposals for ietf protocol groups as part of their charters. particularly SIDROPS should be taking requirements for SIDR protocol deployments from the bgp operating community(ies). So, it's great to get feedback from IXP operators and network operators for requirements/improvements/deployment-guidance. > The idea of the draft is to help with the adoption of RPKI in the domain > of IXPs. > The idea draft is not a replacement for RPKI validation or a global > distribution of RPKI validation results. > The draft is there to help at IXPs till we all drop invalids by default :) > I think ~2yrs back there were more 'problems' with the idea of deployment of route origin validation and taking action(s) upon that decision process. It's possible that in today's review of the problem space the problems have changed or resolved, right? It sounds like, from the discussion, that some operators (of IXP and ISP networks) are saying that: 1) "route origin validation is not as hard to see deploying today" 2) "just introducing an IXP lan/RS that simply implements the validation and takes action(s) is the right course of action" 3) "Using the IXP's RS feed in the case of: 'please drop routes based on validation state' can get data/experience to the IXP participants such that they can then deploy route origin validation in their networks as well" Maybe we can re-frame the discussion along those lines? -chris --000000000000b73b0f05750db7c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I think restating an earlier conversation about this d= raft (which I think was the rpki-light draft name) is useful:
=C2=A0 &qu= ot;The draft aims to provide the ability for a third-party (IXP) to validat= e routes for me, because I can't do that myself"

The reasons why 'I' may not be able to do the validation are perh= aps shifting in time though, which I think should be acknowledged in this c= onversation that's progressed since the original draft was proposed.=C2= =A0

On Fri, Aug 2= 4, 2018 at 10:33 AM Daniel Kopp <daniel.kopp@de-cix.net> wrote:

The initial idea for the draft came from network operators at IXPs.

It's worth noting that -ops groups in the = IETF are supposed to gather requirements from actual operators and coalesce= these into change proposals for ietf protocol groups as part of their char= ters. particularly SIDROPS should be taking requirements for SIDR protocol = deployments from the bgp operating community(ies). So, it's great to ge= t feedback from IXP operators and network operators for requirements/improv= ements/deployment-guidance.
=C2=A0
The idea of the draft is to help with the adoption of RPKI in the domain of= IXPs.
The idea draft is not a replacement for RPKI validation or a global distrib= ution of RPKI validation results.
The draft is there to help at IXPs till we all drop invalids by default :)<= br>

I think ~2yrs back there were more '= ;problems' with the idea of deployment of route origin validation and t= aking action(s) upon that decision process. It's possible that in today= 's review of the problem space the problems have changed or resolved, r= ight? It sounds like, from the discussion, that some operators (of IXP and = ISP networks) are saying that:
=C2=A0 1) "route origin validation i= s not as hard to see deploying today"
=C2=A0 2) "just i= ntroducing an IXP lan/RS that simply implements the validation and takes ac= tion(s) is the right course of action"
=C2=A0 3) "Using= the IXP's RS feed in the case of: 'please drop routes based on val= idation state' can get data/experience to the IXP participants such tha= t they can then deploy route origin validation in their networks as well&qu= ot;

Maybe=C2=A0 we can re-frame the discussion alo= ng those lines?

-chris
--000000000000b73b0f05750db7c7-- From nobody Tue Sep 4 10:08:35 2018 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 7A27B130F52; Tue, 4 Sep 2018 10:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 xmX-ALcYPIvG; Tue, 4 Sep 2018 10:08:27 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 6D30D130DE2; Tue, 4 Sep 2018 10:08:26 -0700 (PDT) X-AuditID: 12074422-4cdff700000065b6-94-5b8ebc0652d0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 52.B6.26038.70CBE8B5; Tue, 4 Sep 2018 13:08:24 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w84H8IAQ018194; Tue, 4 Sep 2018 13:08:19 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w84H89pa025808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Sep 2018 13:08:11 -0400 Date: Tue, 4 Sep 2018 12:08:09 -0500 From: Benjamin Kaduk To: Oleg Muravskiy Cc: The IESG , draft-ietf-sidrops-rpki-tree-validation@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Message-ID: <20180904170806.GI91593@kduck.kaduk.org> References: <153547412129.23827.3324575091222487462.idtracker@ietfa.amsl.com> <4A92D060-389A-4104-A7CF-49984773596B@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A92D060-389A-4104-A7CF-49984773596B@ripe.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nosuxpy/a4PxMNYuOlweYLWb8mchs cXnhRzaL/g1trBa/fz5ltvi2/zibA5vHkiU/mTweTDrK7rHyQG0AcxSXTUpqTmZZapG+XQJX xuerV5gKej0rOmf8Y2pg/GDZxcjJISFgIvHyzBOWLkYuDiGBxUwSc7q/skM4GxglNv6cwQrh XGGSePH8CAtIC4uAisTOY/2sIDYbkN3QfZkZxBYRUJLoam5gBmlgFtjEKPFt6nOwImGBLIm9 v1aA2bxA+56+uwc2SEigXmLyoU6ouKDEyZlPwOLMAuoSf+ZdAhrEAWRLSyz/xwERlpdo3job bBengI3EuvNr2UFsUQFlib19h9gnMArOQjJpFpJJsxAmzUIyaQEjyypG2ZTcKt3cxMyc4tRk 3eLkxLy81CJdU73czBK91JTSTYzgSHBR2sE48Z/XIUYBDkYlHt6Gtr5oIdbEsuLK3EOMkhxM SqK8WTuAQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4o1uAcrwpiZVVqUX5MClpDhYlcV6nc63R QgLpiSWp2ampBalFMFkZDg4lCV693UCNgkWp6akVaZk5JQhpJg5OkOE8QMO7d4EMLy5IzC3O TIfIn2LU5fjzfuokZiGWvPy8VClxXjOQQQIgRRmleXBzQAlMInt/zStGcaC3hHkVQap4gMkP btIroCVMQEuWHOgBWVKSiJCSamB0Y4r0i5z727k7XK1lBZdQ0l3u9+5/tbM0Q98d2aW8+9+x z+eS2ebefm28sV5M3lZEVGOKueG1JTOWyFx5kNSo3VnS5p8ZufHO9M2JEwonZS5RW+3+XefH xCdc71K2HuCP6ly/PVGpWn7Rk31XLC9HHOfc2pVc9d9jQ8Kn28qZYQ611/wq8mSVWIozEg21 mIuKEwE3P/7gOwMAAA== Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT) 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, 04 Sep 2018 17:08:29 -0000 On Mon, Sep 03, 2018 at 12:19:38AM +0200, Oleg Muravskiy wrote: > Hi Benjamin, > > Thanks for your comments. I am updating the draft, please see my inline comments below: > > > On 28 Aug 2018, at 18:35, Benjamin Kaduk wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This document is Informational, so I will make my comments non-blocking, > > but I think that the security considerations could be improved. It > > currently does a good job talking about cases where the procedure can > > receive inconsistent inputs (and how it behaves in the face of those > > inputs), as well as some other considerations, and this is great! I think > > that the discussion could be more powerful if it also considered how those > > inconsistent inputs could be produced, in particular which capabilities an > > attacker could have. There seem to be roughly three classes of actors for > > active attacks -- an attacker in the network could modify the transferred > > content (including number of files and directory layout) over unecrypteed > > rsync or http, an attacker that compromises the webserver's certificate > > (or obtains a fraudulent one) could do the same over encrypted https, and > > an attacker that compromises the TA signing key could produce > > fake-but-"valid" manifests, CRLs, etc.. (Is there more that could be done > > with a compromised non-TA CA? The potential hazards to this algorithm > > don't seem to be noticably distinct, though.) Some consumers may be > > willing to trust in the TA's integrity or even the Web PKI and not worry > > about those risks. Though there is always risk of accidental error, of > > course, and the current coverage in this document seems adequate for that > > risk. > > In the Security Considerations we tried to describe issues specific to our implementation. > What you suggest seems to be a general discussion of vulnerabilities in the RPKI repository architecture that is defined by current standards. I agree that it is missing in the current set of RFCs and it would be great to have it, but on the other hand I do not think it should be done it this document. It would also require another round of going through the WG discussion, I believe. So I left this section as is. I can't fault you for that. Do you think there is any energy to put into a standalone document that covers these topics? > > Some additional section-by-section comments follow. > > > > Section 3.1 > > > > The key properties needed of cryptographic hash functions are either > > "collision resistance" or "second preimage resistance", depending on > > whether the attacker gets to pick both hash inputs (the first case) or only > > one of them (the second). Which one is needed here would probably depend > > on whether the CA/issuer is trusted to not be an attacker or not, but > > regardless, please use the more detailed terminology. > > I’m going for the “collision resistance properties” in that paragraph. > But also note that it isn’t only about attacks on the repository objects: if there are legitimate objects anywhere in fetched repositories that produce the same hashes, they will collide in our implementation. Of course. Even with the "broken" SHA-1 hash, though, such accidental collisions (with different body content) should be vanishingly rare. > > Section 3.2 > > > > [...], or use all objects whose AKI extension > > matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of > > [RFC5280]) of a CA certificate. > > > > "all objects" as discovered within what scope? > > Essentially these are all objects known to a validator at the time the comparison is performed. > I’m changing the draft to read “all known repository objects”. > > > Section 4.2 > > > > Please expand SIA on first usage. > > ACK > > > In bullet point 1, it might help the uninitiated reader to say something > > after "and pass it to the object fetcher" to note that "the fetcher will > > then fetch all objects available from that repository”. > > ACK > > > In bullet point 3, please be more clear about which manifest is "this > > manifest object" that is used to continue validation processing. > > ACK > > > 4. Perform manifest entries discovery and validation as described in > > Section 4.2.2. > > > > nit: "manifest entry discovery" (singular "entry”) > > The manifest contains an entry per object in the publication point, so there are at least 2 entries – for a CA cert and a manifest. > I guess plural “entries” is appropriate here. Ah. I would suggest "discovery of manifest entries", then, though of course the RFC Editor would probably have some suggestsions as well. > > (Note that this implementation uses the operator configuration to > > decide which algorithm to use for path validation. It applies > > selected algorithm to all resource certificates, rather than > > > > nit: "the selected algorithm” > > ACK > > > Please expand ROA on first usage. > > ACK > > > Section 5.1.1, 5.1.2 > > > > The syntactic verification performed here is done on what should be > > considered "untrusted input", which means that the verification code needs > > to be written in a robust manner. (Given the historical recurrences of, > > e.g., ASN.1 decoder security vulnerabilities, we probably need to > > explicitly state this in the security considerations.) > > Well, I could say that the validation “is written and performed in a robust manner”, but I do not see how this will improve the content... I was thinking more along the lines of a note in the security considerations: "The syntactic validation steps performed in Sections 5.1.1 and 5.1.2 are operating on untrusted input, so particular care should be taken to avoid buffer overflows and similar attacks." But this is just a suggestion and I won't be offended if you decide to not use it. > > Section 9.1 > > > > If I understand correctly, RFC 6485 allows for (and predicts the need for) > > hash agility in the file hash algorithm. In this case, it would probably > > be appropriate to say something about how "the security of the system as a > > whole is limited to that of the weakest hash function allowed by consumers, > > but the hash agility provided for by RFC 6485 allows new (stronger) hashes > > to be introduced and old hash functions phased out before they are > > critically broken”. > > The sentence you propose describes the current situation of the RPKI in general, it is not specific to our implementation, or to RPKI tree validation. > > RFC 6485 said: > The recommended procedures to implement such a > transition of key sizes and algorithms is not specified in this > document. > > As such, our validator does not support any other algorithms for keys and hashes. > By now, however, RFC 6485 has been obsoleted by 7935, which refers to RFC 6916 for details of algorithm agility. > > I’m adding a sentence that agility is not supported in our implementation. Okay. That should give the reader a place to start, if they're interested (please informatively cite 6916, too). > > Section 9.2 > > > > In case of a mismatch described above this implementation will not > > exclude an object from further validation merely because it's actual > > > > nit: "its" (no apostrophe) > > ACK > > > Section 9.3 > > > > nit: Which behavior is allowed-but-not-required -- a CA signing things not > > listed in the manifest, or an RP ignoring things not listed in the > > manifest? I suggest "This RP behavior is allowed [...]”. > > ACK > > > Section 9.4 > > > > This kind of behavior would be seen as an unacceptable vulnerability in a > > standards-track protocol, though since this document is only informational > > it does not block publication. > > From the RP perspective it is not possible to know whether the object it received from the remote repository is genuine or tampered with. Current standards require that invalid objects must not be used for validation, and this is what our implementation does. There is no requirement to keep and use an “old” object (whatever that might be) if the “new” one is not valid. Allowing untrusted data that is not authenticated (e.g., by a digital signature) to overwrite existing data in the store that has been authenticated, is something I would not want to see in an IETF protocol. It would only be allowed after the latest manifest has been authenticated and fully processed, and when the "old" resource is no longer referenced by the manifest. This is a matter of the order of operations for processing, more than a perceived requirement to retain an "old" object that is no longer referenced. But, since we are not objecting to the current text, feel free to ignore this discussion point. -Benjamin > > > Section 9.5 > > > > It might be useful to reference Section 5.1.1 and how we sometimes fetch > > the entire repository contents, not limited by a manifest listing. > > ACK > > > Cheers, > Oleg From nobody Tue Sep 4 16:03:43 2018 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 0322B131029 for ; Tue, 4 Sep 2018 16:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 TBVzxOg9sfk5 for ; Tue, 4 Sep 2018 16:03:31 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AAD13104D for ; Tue, 4 Sep 2018 16:03:31 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w84M3PCe062318 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2018 23:03:25 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Christopher Morrow Cc: daniel.kopp@de-cix.net, sidrops@ietf.org References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> From: Nick Hilliard Message-ID: <1c20668c-4785-81e0-a7db-55b36cab8b12@foobar.org> Date: Wed, 5 Sep 2018 00:03:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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, 04 Sep 2018 23:03:41 -0000 Christopher Morrow wrote on 04/09/2018 16:57:> I think restating an earlier conversation about this draft (which I > think was the rpki-light draft name) is useful: > "The draft aims to provide the ability for a third-party (IXP) to > validate routes for me, because I can't do that myself" rather than having a discussion about theoreticals, I set up an RPKI cache from scratch on a VM earlier this evening and tied it into an XR router connected to an IXP. The RPKI cache ran on vanilla centos7 with the RIPE NCC RPKI validator v3 software. Here are the installation instructions for the validator software: > https://github.com/RIPE-NCC/rpki-validator-3/wiki/RIPE-NCC-RPKI-Validator-3-Production Two minor additions were made to the 8 commands required to install the software and get it running: one to get the rpki-rtr process to bind to the public IP address of the server in question, and the second was to install the ARIN TAL. The router was configured to tag and accept invalids. It took 6 lines of copypasta config (3 policy and 3 bgp/rpki) pulled from a couple of quick internet searches to do this. The result of this was a fully operational RPKI PoC which validated prefixes on the router immediately. Embarrassingly, it took longer to beat the firewall into allowing access to the rpki-rtr server than it did either to configure the router or to set up the rpki validator service (this was due to a typo: udp/8323 instead of tcp/8323, oops). In terms of router stack support, rpki validation has been there for years on Junos, IOS-XE, XR, SR-OS, vanilla IOS on some platforms and various other commonly-used router stacks. It's not there on some kit, including, for example, vanilla IOS on older non-core-oriented legacy kit and Mikrotik RouterOS, which gets a mention mostly because it's widely used at IXPs, despite its shortcomings. Obviously a PoC is not a production configuration, but the point of the exercise was to show that the bar for a basic rpki implementation has been lowered to the point of it requiring no more than a skeleton linux deployment and 8 lines of cut-n-paste from a wiki. It isn't rocket science, and it is widely supported on the sorts of routers that people use in production environments, particularly IXPs, i.e. the pool of situations where people can't deploy rpki is continuing to shrink and there is no real operational need to create standardised hacks for situations where it can't be deployed. Nick From nobody Tue Sep 4 23:07:36 2018 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 1B8AC130E5D for ; Tue, 4 Sep 2018 23:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 m4ee9XTBm0Ue for ; Tue, 4 Sep 2018 23:07:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 37CCA128CB7 for ; Tue, 4 Sep 2018 23:07:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fxQyP-0005Rx-QC; Wed, 05 Sep 2018 06:07:30 +0000 Date: Tue, 04 Sep 2018 23:07:29 -0700 Message-ID: From: Randy Bush To: Christopher Morrow Cc: SIDR Operations WG In-Reply-To: References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Wed, 05 Sep 2018 06:07:35 -0000 > 1) "route origin validation is not as hard to see deploying today" see draft-ietf-sidrops-ov-clarify-05.txt. essentially vendors' implementations are funky and so it is hard for me to do it myself. and it is not only ov-clarify. test whether your fave implementation re-evaluates a bgp prefix when a roa change comes in over rpki-rtr. the messy story goes on. > 2) "just introducing an IXP lan/RS that simply implements the validation > and takes action(s) is the right course of action" s/the right course/one right course/ what is nice is that the ixp-provided filter does not have the same problems as above. so it is a leapfrog while hardware vendors catch up. it is driving origin validation deployment. randy From nobody Wed Sep 5 00:35:02 2018 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 CD81A130DE1 for ; Wed, 5 Sep 2018 00:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no autolearn_force=no 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 M39XcKp1NfV6 for ; Wed, 5 Sep 2018 00:34:58 -0700 (PDT) Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) (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 0F6E2128CB7 for ; Wed, 5 Sep 2018 00:34:57 -0700 (PDT) Received: by mail-ed1-f66.google.com with SMTP id l5so5261568edw.9 for ; Wed, 05 Sep 2018 00:34:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GMMjTMeKWvGjrLhlceglpFNpJXzL2Rs5bdoPfoTfzlU=; b=Vh+mmvalm1PFRlrYCvnTRR1gUKzO5kbo2VOsy/NCysZ+Xsm5ozryUh36CFQaoK3arl w7UmmJHArgD5advtixZ4jgz/0OniYAyDC3nALdEAZRk6K9/d2K5KrafLXaj58bctT6JN 06U0rppiISlZVDpoE/rfGG8rus2Fw7jmyTu13zAYVK2RGX1vSboL0WpvtlciSuE3iOSl ZHxFDDNb6E9992RMdtQ7bbC5NFjKl+4vU9HWbBtKRSf5FkE6q4cC/RtmxyN6lylPEmH2 ctWA4K7ZMZJb0sdp2rHM1o4cJqx1/Rlv3oApKfovujvSDBqjeN8kkD/HXggOdGFwXmNh XMwg== X-Gm-Message-State: APzg51Awf9GGvupzw/UVVQ6kuOmCnOGuhzFZ54OeQObrtw/MWfWI5C/5 c3jvnW/86h4GBzf1chzg2d0Ldg== X-Google-Smtp-Source: ANB0Vdb5sbXavtsfq9wZ8H5Q9dIHDyjKbWDBAR6IhRGahBg5AZ3NxEG2KJo5D/M7I3wgGmpe/gl8kw== X-Received: by 2002:a50:cb8c:: with SMTP id k12-v6mr40758858edi.171.1536132896041; Wed, 05 Sep 2018 00:34:56 -0700 (PDT) Received: from localhost (hanna.meerval.net. [192.147.168.57]) by smtp.gmail.com with ESMTPSA id j10-v6sm776957ede.5.2018.09.05.00.34.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 00:34:55 -0700 (PDT) Date: Wed, 5 Sep 2018 09:34:54 +0200 From: Job Snijders To: Randy Bush Cc: Christopher Morrow , SIDR Operations WG Message-ID: <20180905073454.GU3097@hanna.meerval.net> References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Wed, 05 Sep 2018 07:35:00 -0000 On Tue, Sep 04, 2018 at 11:07:29PM -0700, Randy Bush wrote: > > 1) "route origin validation is not as hard to see deploying today" > > see draft-ietf-sidrops-ov-clarify-05.txt. essentially vendors' > implementations are funky and so it is hard for me to do it myself. > > and it is not only ov-clarify. test whether your fave implementation > re-evaluates a bgp prefix when a roa change comes in over rpki-rtr. the > messy story goes on. the IXP route server software (that is used in practise) is provided by a single vendor. Perhaps this single vendor got it right, but from a conceptual point of view they wouldn't be exempted and may still need 'ov-clarify'. > > 2) "just introducing an IXP lan/RS that simply implements the validation > > and takes action(s) is the right course of action" > > s/the right course/one right course/ > > what is nice is that the ixp-provided filter does not have the same > problems as above. because of the single vendor? or because of some other reason? how exactly is their bgp more magic than others? > so it is a leapfrog while hardware vendors catch up. it is driving > origin validation deployment. except that we cannot point at a single instance where the approach has driven origin validation. on the other side, i can point at many instances where IXP route servers have negatively impacted businesses because they propagated/amplified incorrect routing information. What /actually/ drives origin validation is customers asking their providers (be it ISPs or IXPs) to implement origin validation. This approach has already been succesfully tested at FranceIX, AMS-IX, and later this year will be yield positive results at DE-CIX and LINX. I have to ask, (given the author's affiliations) - if this draft is published as an RFC, will you turn back the clock and start propagating invalid route announcements to your customers (marked with an extended community)? Kind regards, Job From nobody Wed Sep 5 00:57:05 2018 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 3AECF130DE1; Wed, 5 Sep 2018 00:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 R7xXJsVbLo2n; Wed, 5 Sep 2018 00:56:56 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 9D402130DC5; Wed, 5 Sep 2018 00:56:55 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fxSgC-0006gX-ER; Wed, 05 Sep 2018 09:56:48 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::11d]) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fxSgB-0008Fs-8P; Wed, 05 Sep 2018 09:56:47 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_85BC2178-6611-49EC-A826-3D634D57E4CE" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Oleg Muravskiy In-Reply-To: <20180904170806.GI91593@kduck.kaduk.org> Date: Wed, 5 Sep 2018 09:56:46 +0200 Cc: The IESG , draft-ietf-sidrops-rpki-tree-validation@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Message-Id: References: <153547412129.23827.3324575091222487462.idtracker@ietfa.amsl.com> <4A92D060-389A-4104-A7CF-49984773596B@ripe.net> <20180904170806.GI91593@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b749e93386b2d2383beac908b7af287a5ef Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT) 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: Wed, 05 Sep 2018 07:56:59 -0000 --Apple-Mail=_85BC2178-6611-49EC-A826-3D634D57E4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HI Benjamin, > On 4 Sep 2018, at 19:08, Benjamin Kaduk wrote: >=20 > On Mon, Sep 03, 2018 at 12:19:38AM +0200, Oleg Muravskiy wrote: >> Hi Benjamin, >>=20 >> Thanks for your comments. I am updating the draft, please see my = inline comments below: >>=20 >>> On 28 Aug 2018, at 18:35, Benjamin Kaduk wrote: >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> This document is Informational, so I will make my comments = non-blocking, >>> but I think that the security considerations could be improved. It >>> currently does a good job talking about cases where the procedure = can >>> receive inconsistent inputs (and how it behaves in the face of those >>> inputs), as well as some other considerations, and this is great! I = think >>> that the discussion could be more powerful if it also considered how = those >>> inconsistent inputs could be produced, in particular which = capabilities an >>> attacker could have. There seem to be roughly three classes of = actors for >>> active attacks -- an attacker in the network could modify the = transferred >>> content (including number of files and directory layout) over = unecrypteed >>> rsync or http, an attacker that compromises the webserver's = certificate >>> (or obtains a fraudulent one) could do the same over encrypted = https, and >>> an attacker that compromises the TA signing key could produce >>> fake-but-"valid" manifests, CRLs, etc.. (Is there more that could = be done >>> with a compromised non-TA CA? The potential hazards to this = algorithm >>> don't seem to be noticably distinct, though.) Some consumers may be >>> willing to trust in the TA's integrity or even the Web PKI and not = worry >>> about those risks. Though there is always risk of accidental error, = of >>> course, and the current coverage in this document seems adequate for = that >>> risk. >>=20 >> In the Security Considerations we tried to describe issues specific = to our implementation. >> What you suggest seems to be a general discussion of vulnerabilities = in the RPKI repository architecture that is defined by current = standards. I agree that it is missing in the current set of RFCs and it = would be great to have it, but on the other hand I do not think it = should be done it this document. It would also require another round of = going through the WG discussion, I believe. So I left this section as = is. >=20 > I can't fault you for that. Do you think there is any energy to put = into a > standalone document that covers these topics? Maybe :) >>> 4. Perform manifest entries discovery and validation as described = in >>> Section 4.2.2. >>>=20 >>> nit: "manifest entry discovery" (singular "entry=E2=80=9D) >>=20 >> The manifest contains an entry per object in the publication point, = so there are at least 2 entries =E2=80=93 for a CA cert and a manifest. >> I guess plural =E2=80=9Centries=E2=80=9D is appropriate here. >=20 > Ah. I would suggest "discovery of manifest entries", then, though of > course the RFC Editor would probably have some suggestsions as well. Sounds good >>> Section 5.1.1, 5.1.2 >>>=20 >>> The syntactic verification performed here is done on what should be >>> considered "untrusted input", which means that the verification code = needs >>> to be written in a robust manner. (Given the historical recurrences = of, >>> e.g., ASN.1 decoder security vulnerabilities, we probably need to >>> explicitly state this in the security considerations.) >>=20 >> Well, I could say that the validation =E2=80=9Cis written and = performed in a robust manner=E2=80=9D, but I do not see how this will = improve the content... >=20 > I was thinking more along the lines of a note in the security > considerations: "The syntactic validation steps performed in Sections = 5.1.1 > and 5.1.2 are operating on untrusted input, so particular care should = be > taken to avoid buffer overflows and similar attacks." But this is = just a > suggestion and I won't be offended if you decide to not use it. Well, this document describes the existing implementation, not how it = should be done. But there is https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/, I = think it would fit there quite well. >>> Section 9.1 >>>=20 >>> If I understand correctly, RFC 6485 allows for (and predicts the = need for) >>> hash agility in the file hash algorithm. In this case, it would = probably >>> be appropriate to say something about how "the security of the = system as a >>> whole is limited to that of the weakest hash function allowed by = consumers, >>> but the hash agility provided for by RFC 6485 allows new (stronger) = hashes >>> to be introduced and old hash functions phased out before they are >>> critically broken=E2=80=9D. >>=20 >> The sentence you propose describes the current situation of the RPKI = in general, it is not specific to our implementation, or to RPKI tree = validation.=20 >>=20 >> RFC 6485 said: >> The recommended procedures to implement such a >> transition of key sizes and algorithms is not specified in this >> document. >>=20 >> As such, our validator does not support any other algorithms for keys = and hashes. >> By now, however, RFC 6485 has been obsoleted by 7935, which refers to = RFC 6916 for details of algorithm agility. >>=20 >> I=E2=80=99m adding a sentence that agility is not supported in our = implementation. >=20 > Okay. That should give the reader a place to start, if they're = interested > (please informatively cite 6916, too). OK >>> This kind of behavior would be seen as an unacceptable vulnerability = in a >>> standards-track protocol, though since this document is only = informational >>> it does not block publication. >>=20 >> =46rom the RP perspective it is not possible to know whether the = object it received from the remote repository is genuine or tampered = with. Current standards require that invalid objects must not be used = for validation, and this is what our implementation does. There is no = requirement to keep and use an =E2=80=9Cold=E2=80=9D object (whatever = that might be) if the =E2=80=9Cnew=E2=80=9D one is not valid. >=20 > Allowing untrusted data that is not authenticated (e.g., by a digital > signature) to overwrite existing data in the store that has been > authenticated, is something I would not want to see in an IETF = protocol. > It would only be allowed after the latest manifest has been = authenticated > and fully processed, and when the "old" resource is no longer = referenced by > the manifest. This is a matter of the order of operations for = processing, > more than a perceived requirement to retain an "old" object that is no > longer referenced. But, since we are not objecting to the current = text, > feel free to ignore this discussion point. OK, thanks for your input. I do agree with that, and I think it would not be difficult to fix it in = our code and make a maintenance release. =E2=80=94=20 Oleg= --Apple-Mail=_85BC2178-6611-49EC-A826-3D634D57E4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 HI = Benjamin,

On 4 Sep 2018, at 19:08, Benjamin Kaduk = <kaduk@mit.edu> = wrote:

On Mon, Sep 03, 2018 at = 12:19:38AM +0200, Oleg Muravskiy wrote:
Hi Benjamin,

Thanks for your comments. I am updating the draft, please see = my inline comments below:

On 28 Aug 2018, at 18:35, Benjamin Kaduk <kaduk@mit.edu> wrote:
---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

This document is Informational, so = I will make my comments non-blocking,
but I think that the = security considerations could be improved.  It
currently does a good job talking about cases where the = procedure can
receive inconsistent inputs (and how it = behaves in the face of those
inputs), as well as some = other considerations, and this is great!  I think
that = the discussion could be more powerful if it also considered how those
inconsistent inputs could be produced, in particular which = capabilities an
attacker could have.  There seem to = be roughly three classes of actors for
active attacks -- = an attacker in the network could modify the transferred
content (including number of files and directory layout) over = unecrypteed
rsync or http, an attacker that compromises = the webserver's certificate
(or obtains a fraudulent one) = could do the same over encrypted https, and
an attacker = that compromises the TA signing key could produce
fake-but-"valid" manifests, CRLs, etc..  (Is there more = that could be done
with a compromised non-TA CA?  The = potential hazards to this algorithm
don't seem to be = noticably distinct, though.)  Some consumers may be
willing to trust in the TA's integrity or even the Web PKI = and not worry
about those risks.  Though there is = always risk of accidental error, of
course, and the = current coverage in this document seems adequate for that
risk.

In the = Security Considerations we tried to describe issues specific to our = implementation.
What you suggest seems to be a general = discussion of vulnerabilities in the RPKI repository architecture that = is defined by current standards. I agree that it is missing in the = current set of RFCs and it would be great to have it, but on the other = hand I do not think it should be done it this document. It would also = require another round of going through the WG discussion, I believe. So = I left this section as is.

I can't fault you for that. =  Do you think there is any energy to put into a
standalone document that covers = these topics?

Maybe = :)

 4.  Perform = manifest entries discovery and validation as described in
     Section 4.2.2.

nit: "manifest entry discovery" (singular "entry=E2=80=9D)

The manifest contains an entry = per object in the publication point, so there are at least 2 entries =E2=80= =93 for a CA cert and a manifest.
I guess plural = =E2=80=9Centries=E2=80=9D is appropriate here.

Ah.  I would suggest "discovery of manifest entries", = then, though of
course the RFC Editor would probably have some suggestsions = as well.

Sounds = good

Section 5.1.1, 5.1.2

The syntactic verification performed here is = done on what should be
considered "untrusted input", which = means that the verification code needs
to be written in a = robust manner.  (Given the historical recurrences of,
e.g., ASN.1 decoder security vulnerabilities, we probably = need to
explicitly state this in the security = considerations.)

Well, I could = say that the validation =E2=80=9Cis written and performed in a robust = manner=E2=80=9D, but I do not see how this will improve the = content...

I was thinking more along the lines of a note in the = security
considerations:=  "The syntactic validation steps performed in Sections = 5.1.1
and 5.1.2 are = operating on untrusted input, so particular care should be
taken to avoid buffer overflows = and similar attacks."  But this is just a
suggestion and I won't be = offended if you decide to not use it.

Well, this document describes the existing = implementation, not how it should be done.
But there is https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/, = I think it would fit there quite well.

Section 9.1

If I understand correctly, RFC 6485 allows for = (and predicts the need for)
hash agility in the file hash = algorithm.  In this case, it would probably
be = appropriate to say something about how "the security of the system as = a
whole is limited to that of the weakest hash function = allowed by consumers,
but the hash agility provided for by = RFC 6485 allows new (stronger) hashes
to be introduced and = old hash functions phased out before they are
critically = broken=E2=80=9D.

The sentence = you propose describes the current situation of the RPKI in general, it = is not specific to our implementation, or to RPKI tree validation. 

RFC 6485 said:
  The recommended = procedures to implement such a
  transition of = key sizes and algorithms is not specified in this
  document.

As such, = our validator does not support any other algorithms for keys and = hashes.
By now, however, RFC 6485 has been obsoleted by = 7935, which refers to RFC 6916 for details of algorithm agility.

I=E2=80=99m adding a sentence that agility is = not supported in our implementation.

Okay.  That should give the = reader a place to start, if they're interested
(please informatively cite 6916, = too).

OK

This kind of behavior would be seen as an unacceptable = vulnerability in a
standards-track protocol, though since = this document is only informational
it does not block = publication.

=46rom the RP = perspective it is not possible to know whether the object it received = from the remote repository is genuine or tampered with. Current = standards require that invalid objects must not be used for validation, = and this is what our implementation does. There is no requirement to = keep and use an =E2=80=9Cold=E2=80=9D object (whatever that might be) if = the =E2=80=9Cnew=E2=80=9D one is not valid.
Allowing untrusted data that is = not authenticated (e.g., by a digital
signature) to overwrite existing data in the store that has = been
authenticated, = is something I would not want to see in an IETF protocol.
It would only be allowed after = the latest manifest has been authenticated
and fully processed, and when the "old" resource is no longer = referenced by
the manifest. =  This is a matter of the order of operations for = processing,
more than a = perceived requirement to retain an "old" object that is no
longer referenced.  But, = since we are not objecting to the current text,
feel free to ignore this = discussion point.

OK, thanks for your input.
I do agree with = that, and I think it would not be difficult to fix it in our code and = make a maintenance release.



=E2=80=94 
Oleg
= --Apple-Mail=_85BC2178-6611-49EC-A826-3D634D57E4CE-- From nobody Wed Sep 5 07:51:20 2018 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 402FB130E2E for ; Wed, 5 Sep 2018 07:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yTP3lJmGosB3 for ; Wed, 5 Sep 2018 07:51:16 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D926A126CC7 for ; Wed, 5 Sep 2018 07:51:15 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w85Dp8Mp077048 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Sep 2018 14:51:09 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Randy Bush Cc: Christopher Morrow , SIDR Operations WG References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> From: Nick Hilliard Message-ID: Date: Wed, 5 Sep 2018 15:51:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Wed, 05 Sep 2018 14:51:19 -0000 Randy Bush wrote on 05/09/2018 07:07: > and it is not only ov-clarify. test whether your fave implementation > re-evaluates a bgp prefix when a roa change comes in over rpki-rtr. the > messy story goes on. [...] > what is nice is that the ixp-provided filter does not have the same > problems as above. really it does. As Job suggested, the majority of ixp route servers run BIRD, and taking the example you mention, one of BIRD's known limitations is that it does not handle revalidation. Another limitation would be that it doesn't handle aggregators as the last element in the as path. In general, if the IXP uses any particular bgp stack (whether ios-xe, junos, bird, etc), it will be stuck with the bugs and shortcomings of that particular implementation, and under the proposals of the validating-bgp-speaker draft, everyone at the ixp will be subject to those particular bugs and shortcomings. It's not valid to say that the IXP rpki implementation will be any better than a "hardware" router because - as Job pointed out already - it's just software under the hood. Nick From nobody Wed Sep 5 07:56:17 2018 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 71F67130E2E for ; Wed, 5 Sep 2018 07:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 TrQ-o-stNB7I for ; Wed, 5 Sep 2018 07:56:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 356B7126CC7 for ; Wed, 5 Sep 2018 07:56:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fxZE4-0006tr-0N; Wed, 05 Sep 2018 14:56:12 +0000 Date: Wed, 05 Sep 2018 07:56:11 -0700 Message-ID: From: Randy Bush To: Nick Hilliard Cc: Christopher Morrow , SIDR Operations WG In-Reply-To: References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Wed, 05 Sep 2018 14:56:16 -0000 > As Job suggested, the majority of ixp route servers run BIRD, and > taking the example you mention, one of BIRD's known limitations is > that it does not handle revalidation. then it is pretty much useless. > Another limitation would be that it doesn't handle aggregators as the > last element in the as path. don't care. they're irrelevant. randy From nobody Wed Sep 5 08:06:57 2018 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 236C2130E3C for ; Wed, 5 Sep 2018 08:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 swJye8bf85Hm for ; Wed, 5 Sep 2018 08:06:52 -0700 (PDT) Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 06777130DF4 for ; Wed, 5 Sep 2018 08:06:51 -0700 (PDT) Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fxZOL-0009TC-AD (job@us.ntt.net) for sidrops@ietf.org; Wed, 05 Sep 2018 15:06:51 +0000 Received: by mail-oi0-f50.google.com with SMTP id x197-v6so14236186oix.5 for ; Wed, 05 Sep 2018 08:06:49 -0700 (PDT) X-Gm-Message-State: APzg51AMHmtCV4xepSRD5u962nAi/a7AqhZC9YRafAcEHuv6CZXCLP3c oOXJefuw48BO8D68NB5sKVilEjBjrLUGw4qa9HeozQ== X-Google-Smtp-Source: ANB0VdY1JH6pb2u7b3MQU6USQYeKUtwIIXfShv5A+5byIQ2NrPut5kw+A7p1zAqYjLGvo0BIwAHzoEiAT+GRJEEzNfs= X-Received: by 2002:aca:bbc4:: with SMTP id l187-v6mr27893561oif.278.1536160008915; Wed, 05 Sep 2018 08:06:48 -0700 (PDT) MIME-Version: 1.0 References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> In-Reply-To: From: Job Snijders Date: Wed, 5 Sep 2018 17:06:38 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Randy Bush Cc: Christopher Morrow , Nick Hilliard , SIDR Operations WG Content-Type: multipart/alternative; boundary="000000000000a67b890575211f1d" Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Wed, 05 Sep 2018 15:06:55 -0000 --000000000000a67b890575211f1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, As an experiment, can FranceIX and DE-CIX propagate a more-specific of the AMS-IX peering LAN prefix via their route servers (but clearly mark it with an extended community). This way, all the authors=E2=80=99 organizations, c= an make observations on customer feedback. In the hours that follow we can perhaps learn of the consequences of willingly propagating RPKI invalid route announcements. This would be a repeat of the incident that happenend at DE-CIX on December 5th, 2017. I hope people still remember. Kind regards, Job On Wed, 5 Sep 2018 at 16:56, Randy Bush wrote: > > As Job suggested, the majority of ixp route servers run BIRD, and > > taking the example you mention, one of BIRD's known limitations is > > that it does not handle revalidation. > > then it is pretty much useless. > > > Another limitation would be that it doesn't handle aggregators as the > > last element in the as path. > > don't care. they're irrelevant. > > randy > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --000000000000a67b890575211f1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As an experiment, can FranceIX and DE-CIX propagate a more-spe= cific of the AMS-IX peering LAN prefix via their route servers (but clearly= mark it with an extended community). This way, all the authors=E2=80=99 or= ganizations, can make observations on customer feedback.

In the hours that follow we can = perhaps learn of the consequences of willingly propagating RPKI invalid rou= te announcements.

This w= ould be a repeat of the incident that happenend at DE-CIX on December 5th, = 2017. I hope people still remember.

Kind regards,

Job
--000000000000a67b890575211f1d-- From nobody Wed Sep 5 09:32:42 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F062912426A; Wed, 5 Sep 2018 09:32:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153616515997.19878.5372380505646461043.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2018 09:32:39 -0700 Archived-At: Subject: [Sidrops] sidrops - New Meeting Session Request for IETF 103 X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 16:32:40 -0000 A new meeting session request has just been submitted by Chris Morrow, a Chair of the sidrops working group. --------------------------------------------------------- Working Group Name: SIDR Operations Area Name: Operations and Management Area Session Requester: Chris Morrow Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: idr grow Second Priority: opsarea opsec Third Priority: opsawg People who must be present: Keyur Patel Alvaro Retana Chris Morrow Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Sep 5 09:38:28 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56207130EB1; Wed, 5 Sep 2018 09:38:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153616548926.19887.5663371721961609778@ietfa.amsl.com> Date: Wed, 05 Sep 2018 09:38:09 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-02.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 16:38:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGPsec Algorithms, Key Formats, and Signature Formats Authors : Sean Turner Oliver Borchert Filename : draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-02.txt Pages : 22 Date : 2018-09-05 Abstract: This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-02 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 5 09:40:15 2018 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 3034A130E9A for ; Wed, 5 Sep 2018 09:40:06 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 d_PK5g9QDM-G for ; Wed, 5 Sep 2018 09:40:03 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 C9479130E94 for ; Wed, 5 Sep 2018 09:40:02 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id m26-v6so6344479uap.2 for ; Wed, 05 Sep 2018 09:40:02 -0700 (PDT) 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=+tEqWDGHNWykm24fQW/KEiO6ydJyP+frwPROhyqmfVs=; b=f4TbFyLN+Oh6Sn4isRG5DVaMfCMJ0JExODhuQbRJslL9kiXCpTzdWyTaF9iTHDFKyi 4jrNk/REgiCLAVX17l9J42jbt1DUx2okXMnlZbEt5auzlQm/xRTzC9WR7mPg/6k2ZbCT o8fIULleKtVNk1hPSuXRYMWYhZDbBO2gm5BCtXu/NK8di2eVGg4zFoOiAxsnKKhY6w3C xkylukfnKtuEQaXLX8ZhqruUmirv1TPNeypHDJ3VtxIlhJrqlYghReATILxgnFw0qnVj dlZl58ty8ESC1LuNaYUlOawwFyxjNMFkoBVlaZRTywLT70t0rATnaJ+J0L3Zku2kIjz3 fHdg== 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=+tEqWDGHNWykm24fQW/KEiO6ydJyP+frwPROhyqmfVs=; b=AnsG7ei0AxPqEllrlwUf6ZO4qu9C+oNITsyEo3w6G2EzADMmVIQwkCY+jy8NeaOpj4 /kHGUdztYU1sEhveA+9Eeq2ETNTGm4TA3FO4Tjf0PbFQcmplb2Ljz8AVxcdDGssXQwbe IFin0dj3AX3mKzCXTxKhh7DF7aOO3qpuPd6SOSXPWTpwzd1UQEHeczHwWN1H9NWQv+yC WW31T4A1F7YoDs3kocywRtc1JvD7f42rpM7FamGcR8qK1pfT6CssYfckqEXh420zvClD UOyimaH7z6P5lY8A7/r7ciXzChGaE2ojpODUvIAuGOMlLQWyuPXBOshlVgUsn94K2DAp T+mg== X-Gm-Message-State: APzg51D+/9x5DA4tozP+/aH9rqlp2MrpGWluteZ8DLu2fP/SZNUHqjdV /pZinJvzj69EnuSkyuvTE8J2rgT61bSPpMAyK3gWHQ== X-Google-Smtp-Source: ANB0VdbvoEPg47nNdccX7GBKiERyicpQQViHvUCR8zQz4IzsjA8DRxw/AZKFNN8xv/qfHosFflWzee4cYiRkLu+lykQ= X-Received: by 2002:a67:f68d:: with SMTP id n13-v6mr13145861vso.87.1536165601472; Wed, 05 Sep 2018 09:40:01 -0700 (PDT) MIME-Version: 1.0 References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> In-Reply-To: From: Christopher Morrow Date: Wed, 5 Sep 2018 12:39:49 -0400 Message-ID: To: Randy Bush Cc: Nick Hilliard , sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000fdf6400575226c64" Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Wed, 05 Sep 2018 16:40:14 -0000 --000000000000fdf6400575226c64 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 5, 2018 at 10:56 AM Randy Bush wrote: > > As Job suggested, the majority of ixp route servers run BIRD, and > > taking the example you mention, one of BIRD's known limitations is > > that it does not handle revalidation. > > then it is pretty much useless. > > "is pretty much useless" - Needs bug(s) filed and development work in order to rectify this problem. I'd caution against: "is useless, never talk to it again" because ... ideally we want all the bgp software folk to do the right thing here, right? so ideally ov-clarify already whacks "popular hardware vendors" on the nose, let's make sure the 'popular software vendors' also have bugs filed against them? > > Another limitation would be that it doesn't handle aggregators as the > > last element in the as path. > > don't care. they're irrelevant. > > "they are irrelevant" - because of the total DFZ there are X% and of that set Y% have a supernet with the same path so the subnet 'does not matter' for routing's behaviour. right? > randy > --000000000000fdf6400575226c64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Sep 5, 2018 at 10:56 AM Randy Bush <r= andy@psg.com> wrote:
> As= Job suggested, the majority of ixp route servers run BIRD, and
> taking the example you mention, one of BIRD's known limitations is=
> that it does not handle revalidation.

then it is pretty much useless.=C2=A0


"is pretty much useless" - N= eeds bug(s) filed and development work in order to rectify this problem.
I'd caution against: "is useless, never talk to it again&q= uot; because ... ideally we want all the bgp software folk to do the right = thing here, right?
=C2=A0so ideally ov-clarify already whacks &qu= ot;popular hardware vendors" on the nose, let's make sure the '= ;popular software vendors' also have bugs filed against them?
=C2=A0
> Another limitation would be that it doesn't handle aggregators as = the
> last element in the as path.

don't care.=C2=A0 they're irrelevant.


"they are irrelevant" - beca= use of the total DFZ there are X% and of that set Y% have a supernet with t= he same path so the subnet 'does not matter' for routing's beha= viour.

right?
=C2=A0
randy
--000000000000fdf6400575226c64-- From nobody Wed Sep 5 14:23:14 2018 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 90B74130DCC; Wed, 5 Sep 2018 14:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RaO4EhIa8Pld; Wed, 5 Sep 2018 14:23:02 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 53A92130DC9; Wed, 5 Sep 2018 14:23:02 -0700 (PDT) X-AuditID: 1209190d-e8dff70000001af6-0d-5b904934a962 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C0.B0.06902.439409B5; Wed, 5 Sep 2018 17:23:01 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w85LMtSM002520; Wed, 5 Sep 2018 17:22:57 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w85LMpfS022644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Sep 2018 17:22:53 -0400 Date: Wed, 5 Sep 2018 16:22:51 -0500 From: Benjamin Kaduk To: Oleg Muravskiy Cc: The IESG , draft-ietf-sidrops-rpki-tree-validation@ietf.org, Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org Message-ID: <20180905212251.GF73164@kduck.kaduk.org> References: <153547412129.23827.3324575091222487462.idtracker@ietfa.amsl.com> <4A92D060-389A-4104-A7CF-49984773596B@ripe.net> <20180904170806.GI91593@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nrmvqOSHa4O9rPouOlweYLWb8mchs cXnhRzaL/g1trBa/fz5ltvi2/zibA5vHkiU/mTweTDrK7rHyQG0AcxSXTUpqTmZZapG+XQJX xoaNvxkLHltV/N12grWB8aFeFyMnh4SAicTVeXOYuhi5OIQEFjNJPP0xix3C2cAosWLtGzYI 5wqTxMFTj5lBWlgEVCQmbFzHBmKzAdkN3ZfB4iICShJdzQ3MIA3MApsYJb5Nfc4KkhAWyJLY +2sFkM3BwQu0b/+tWIihdxglzpw4xQhSwysgKHFy5hMWEJtZQF3iz7xLzCD1zALSEsv/cUCE 5SWat84G28UpYCPxcPJnsPGiAsoSe/sOsU9gFJyFZNIsJJNmIUyahWTSAkaWVYyyKblVurmJ mTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGEGRwCnJu4Px312vQ4wCHIxKPLw/LvRHC7EmlhVX 5h5ilORgUhLllfEACvEl5adUZiQWZ8QXleakFh9ilOBgVhLhbX8PlONNSaysSi3Kh0lJc7Ao ifM6nmuNFhJITyxJzU5NLUgtgsnKcHAoSfCKeEyIFhIsSk1PrUjLzClBSDNxcIIM5wEaftwd qIa3uCAxtzgzHSJ/ilGX48/7qZOYhVjy8vNSpcR5zUAGCYAUZZTmwc0BJTCJ7P01rxjFgd4S 5l0MUsUDTH5wk14BLWECWrLkQA/IkpJEhJRUA6Pf0/XPz6hZOvTKLl4ydT536LefxTO2mMpF 2Apz7xf/zLtae87e2q6bK2Uy/vDuKKyVvnVaqyiw5JR64KYEo28VU0zdJpzusjym7BdTf7Xu dHKmzKcXhYzNpz6ecHzdKh58JsAhamFLThLj2XiWW53/HGTZP73rXOWc4m2t85+v2GqnrUHm dCWW4oxEQy3mouJEAEiSxTY7AwAA Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT) 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: Wed, 05 Sep 2018 21:23:06 -0000 On Wed, Sep 05, 2018 at 09:56:46AM +0200, Oleg Muravskiy wrote: > HI Benjamin, > > > On 4 Sep 2018, at 19:08, Benjamin Kaduk wrote: > > > > On Mon, Sep 03, 2018 at 12:19:38AM +0200, Oleg Muravskiy wrote: > >> Hi Benjamin, > >> > >> Thanks for your comments. I am updating the draft, please see my inline comments below: > >> > >>> On 28 Aug 2018, at 18:35, Benjamin Kaduk wrote: > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> This document is Informational, so I will make my comments non-blocking, > >>> but I think that the security considerations could be improved. It > >>> currently does a good job talking about cases where the procedure can > >>> receive inconsistent inputs (and how it behaves in the face of those > >>> inputs), as well as some other considerations, and this is great! I think > >>> that the discussion could be more powerful if it also considered how those > >>> inconsistent inputs could be produced, in particular which capabilities an > >>> attacker could have. There seem to be roughly three classes of actors for > >>> active attacks -- an attacker in the network could modify the transferred > >>> content (including number of files and directory layout) over unecrypteed > >>> rsync or http, an attacker that compromises the webserver's certificate > >>> (or obtains a fraudulent one) could do the same over encrypted https, and > >>> an attacker that compromises the TA signing key could produce > >>> fake-but-"valid" manifests, CRLs, etc.. (Is there more that could be done > >>> with a compromised non-TA CA? The potential hazards to this algorithm > >>> don't seem to be noticably distinct, though.) Some consumers may be > >>> willing to trust in the TA's integrity or even the Web PKI and not worry > >>> about those risks. Though there is always risk of accidental error, of > >>> course, and the current coverage in this document seems adequate for that > >>> risk. > >> > >> In the Security Considerations we tried to describe issues specific to our implementation. > >> What you suggest seems to be a general discussion of vulnerabilities in the RPKI repository architecture that is defined by current standards. I agree that it is missing in the current set of RFCs and it would be great to have it, but on the other hand I do not think it should be done it this document. It would also require another round of going through the WG discussion, I believe. So I left this section as is. > > > > I can't fault you for that. Do you think there is any energy to put into a > > standalone document that covers these topics? > > Maybe :) I'd be happy to see one, though I probably could not be the driving force myself. > >>> 4. Perform manifest entries discovery and validation as described in > >>> Section 4.2.2. > >>> > >>> nit: "manifest entry discovery" (singular "entry”) > >> > >> The manifest contains an entry per object in the publication point, so there are at least 2 entries – for a CA cert and a manifest. > >> I guess plural “entries” is appropriate here. > > > > Ah. I would suggest "discovery of manifest entries", then, though of > > course the RFC Editor would probably have some suggestsions as well. > > Sounds good > > >>> Section 5.1.1, 5.1.2 > >>> > >>> The syntactic verification performed here is done on what should be > >>> considered "untrusted input", which means that the verification code needs > >>> to be written in a robust manner. (Given the historical recurrences of, > >>> e.g., ASN.1 decoder security vulnerabilities, we probably need to > >>> explicitly state this in the security considerations.) > >> > >> Well, I could say that the validation “is written and performed in a robust manner”, but I do not see how this will improve the content... > > > > I was thinking more along the lines of a note in the security > > considerations: "The syntactic validation steps performed in Sections 5.1.1 > > and 5.1.2 are operating on untrusted input, so particular care should be > > taken to avoid buffer overflows and similar attacks." But this is just a > > suggestion and I won't be offended if you decide to not use it. > > Well, this document describes the existing implementation, not how it should be done. > But there is https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/, I think it would fit there quite well. Fair enough. Do I need to send mail or make a pull request or anything like that, or are the wheels already moving on this one? Thanks, Benjamin > >>> Section 9.1 > >>> > >>> If I understand correctly, RFC 6485 allows for (and predicts the need for) > >>> hash agility in the file hash algorithm. In this case, it would probably > >>> be appropriate to say something about how "the security of the system as a > >>> whole is limited to that of the weakest hash function allowed by consumers, > >>> but the hash agility provided for by RFC 6485 allows new (stronger) hashes > >>> to be introduced and old hash functions phased out before they are > >>> critically broken”. > >> > >> The sentence you propose describes the current situation of the RPKI in general, it is not specific to our implementation, or to RPKI tree validation. > >> > >> RFC 6485 said: > >> The recommended procedures to implement such a > >> transition of key sizes and algorithms is not specified in this > >> document. > >> > >> As such, our validator does not support any other algorithms for keys and hashes. > >> By now, however, RFC 6485 has been obsoleted by 7935, which refers to RFC 6916 for details of algorithm agility. > >> > >> I’m adding a sentence that agility is not supported in our implementation. > > > > Okay. That should give the reader a place to start, if they're interested > > (please informatively cite 6916, too). > > OK > > >>> This kind of behavior would be seen as an unacceptable vulnerability in a > >>> standards-track protocol, though since this document is only informational > >>> it does not block publication. > >> > >> From the RP perspective it is not possible to know whether the object it received from the remote repository is genuine or tampered with. Current standards require that invalid objects must not be used for validation, and this is what our implementation does. There is no requirement to keep and use an “old” object (whatever that might be) if the “new” one is not valid. > > > > Allowing untrusted data that is not authenticated (e.g., by a digital > > signature) to overwrite existing data in the store that has been > > authenticated, is something I would not want to see in an IETF protocol. > > It would only be allowed after the latest manifest has been authenticated > > and fully processed, and when the "old" resource is no longer referenced by > > the manifest. This is a matter of the order of operations for processing, > > more than a perceived requirement to retain an "old" object that is no > > longer referenced. But, since we are not objecting to the current text, > > feel free to ignore this discussion point. > > OK, thanks for your input. > I do agree with that, and I think it would not be difficult to fix it in our code and make a maintenance release. > > > > — > Oleg From nobody Thu Sep 6 06:21:59 2018 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 3CDEE130E0A for ; Thu, 6 Sep 2018 06:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QGXZ-YQNw9_N for ; Thu, 6 Sep 2018 06:21:54 -0700 (PDT) Received: from de-cix.net (relay4.de-cix.net [46.31.121.24]) (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 9F121130E1F for ; Thu, 6 Sep 2018 06:21:53 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.53,338,1531778400"; d="p7s'?scan'208"; a="2326556" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw014.de-cix.net with ESMTP; 06 Sep 2018 15:21:51 +0200 Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 5E607B00B8; Thu, 6 Sep 2018 15:21:50 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 6 Sep 2018 15:21:50 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1367.000; Thu, 6 Sep 2018 15:21:50 +0200 From: Daniel Kopp To: Job Snijders CC: SIDR Operations WG Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 Thread-Index: AQHUOie94b+qhBJXv0aVQvhLDzuGmaTL0PCAgAMH8YCAEWE/gIAA7XyAgAAYbQCAAfNFgA== Date: Thu, 6 Sep 2018 13:21:49 +0000 Message-ID: <16AB499B-D859-48D2-9C36-AAF4C6F29B1C@de-cix.net> References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> <20180905073454.GU3097@hanna.meerval.net> In-Reply-To: <20180905073454.GU3097@hanna.meerval.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.6.18) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.60.10] Content-Type: multipart/signed; boundary="Apple-Mail=_286DF6FB-4315-4893-89D0-D5544C1E3313"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Thu, 06 Sep 2018 13:21:57 -0000 --Apple-Mail=_286DF6FB-4315-4893-89D0-D5544C1E3313 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5. Sep 2018, at 09:34, Job Snijders wrote: >=20 > I have to ask, (given the author's affiliations) - if this draft is > published as an RFC, will you turn back the clock and start = propagating > invalid route announcements to your customers (marked with an extended > community)?=20 It=E2=80=99s not turning back the clocks. There is no origin validation = at DE-CIX yet and as far as I know, DE-CIX wanted the draft to drive the = implementation. Moreover the draft defines the different modes of operations, so as far = as I know also AMS-IX wants to add the tagging to their current = implementation. Kind regards, Daniel=20 --Apple-Mail=_286DF6FB-4315-4893-89D0-D5544C1E3313 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBjCCBkAw ggUooAMCAQICFHyxDwExx02H4STp1P4iVRvBZ68RMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMjAeFw0xNzExMjcxMzMyMjFaFw0yMjExMjcxMzMyMjFaMIGMMQsw CQYDVQQGEwJERTEfMB0GA1UEChMWREUtQ0lYIE1hbmFnZW1lbnQgR21iSDEfMB0GA1UECwwWUmVz ZWFyY2ggJiBEZXZlbG9wbWVudDElMCMGCSqGSIb3DQEJARYWZGFuaWVsLmtvcHBAZGUtY2l4Lm5l dDEUMBIGA1UEAxMLRGFuaWVsIEtvcHAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDk Jvo9dsDe4/cugYUYjg+L7qzCYJ2Z4OZKuzidzBMh/POQQOO/AA/pczvnkasmswAsPvESoQFih4EI 3i5VJozg81wGOSe1iDmaB8OJSyaA8dN2coOo4266Xmx7RPRvoU4cfGU+AOlYazzO76AWmMomgMc/ 7bWbuzFSB8RQ9FwVgNxqQXXIOPwYSXKA5z7f46S0uYfMxsxdf0cuwqI1uxPdKi6z+mG8MJOk7VVM Ru5eXVUSHbwCzi9aItNkHwu0kADYk9mAEY9dtuhIoE2ZgzAq0gRcEYVGpcZW8THhutqElE59z2at G9qbTIbIFkmIQUiSxkCssyKxXhViZL4PpP/pAgMBAAGjggLNMIICyTAhBgNVHREEGjAYgRZkYW5p ZWwua29wcEBkZS1jaXgubmV0MA4GA1UdDwEB/wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDBDAd BgNVHQ4EFgQU9G9KiD0soUVY6ZoVKSASO+LMWhswHwYDVR0jBBgwFoAU8MejMpG168q1WHcVp06+ Gl1hQyUwgf8GA1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDovL2NybC5zd2lzc3NpZ24ubmV0L0YwQzdB MzMyOTFCNUVCQ0FCNTU4NzcxNUE3NEVCRTFBNUQ2MTQzMjUwgaiggaWggaKGgZ9sZGFwOi8vZGly ZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049RjBDN0EzMzI5MUI1RUJDQUI1NTg3NzE1QTc0RUJFMUE1 RDYxNDMyNSUyQ089U3dpc3NTaWduJTJDQz1DSD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jh c2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwYQYDVR0gBFowWDBWBglghXQBWQED AQYwSTBHBggrBgEFBQcCARY7aHR0cDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS9Td2lzc1Np Z24tU2lsdmVyLUNQLUNQUy5wZGYwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlhodHRw Oi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkxQjVF QkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVyLXBl cnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRF QkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQCRy7o0H3gyfjNudjAi+zZltdsfYG27vYqQ fKHl32E3J383bMIGdyhFtBv+0qtQyIsz3QZnUb8PnJ72ap2x1e3zGhw2+vbd8K/1aROe1vd0wdVG /muRCLSUPn8K2+wzAxtvAWwJRORPkeTxkiMY0Cve5n6/qigvUyvbMFCO09Mp2NHzBxqKXyI027Zy b34iKso23ycueRREdG0PNTOd/CwX3XuS/Mr2A/mmsX9B7PWdcjbaE3qOPhg1p8mp0SImPuHAl7p0 UEVDqBt4XTOKJRZv6KJD/tdIonyFQdj/FgTYncl8N7BJLwO/qHxATlmKXogdLAe6Ifyam8DHeHgK 9mUMMIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNV BAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2ZXIg Q0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNIMRUw EwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2ZXIg Q0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJobzD g6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDvALLr EzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2Yru5 aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5rgtmQ DAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kVmJyU U8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQXoM3B 5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2ln bi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCBooaB n2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIzQkNC NDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAEWjBY MFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24u Y29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYIKwYB BQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2FkLzE3 QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0dHA6 Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZB ODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkdaI3K CNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsponPe l/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZVKIh jfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0wl+S 4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8u7mO lL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQwJtE QK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/mpaG /ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8N43x Hm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4Fg9q 2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uoxggL2MIIC8gIBATBuMFYxCzAJBgNVBAYTAkNIMRUwEwYD VQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0Eg MjAxNCAtIEcyMgIUfLEPATHHTYfhJOnU/iJVG8FnrxEwCQYFKw4DAhoFAKCCAV0wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwOTA2MTMyMTUyWjAjBgkqhkiG9w0B CQQxFgQUcZYsjaEvvwJjTv45O4AGCy5i5zEwfQYJKwYBBAGCNxAEMXAwbjBWMQswCQYDVQQGEwJD SDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1NpZ24gUGVyc29uYWwgU2ls dmVyIENBIDIwMTQgLSBHMjICFHyxDwExx02H4STp1P4iVRvBZ68RMH8GCyqGSIb3DQEJEAILMXCg bjBWMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1Np Z24gUGVyc29uYWwgU2lsdmVyIENBIDIwMTQgLSBHMjICFHyxDwExx02H4STp1P4iVRvBZ68RMA0G CSqGSIb3DQEBAQUABIIBALAzk92cF+voxjP/FEHJA5TrTpHzuXyEKHJdncUhTaka6ZrUs/lCnzuh 9PDmCHli/6HQaw0rgKDjQTRJwuS/vu6DhoCeCaZA2yrOwESLeu3iWVJ1bT0Bv59Ee1Vfj0hrrQ0K OsmngV3/9iXV54jz0HahbDTiqjUXSO0e1+7A4aTa+S+xSWFoPrEuNqc3H0pR1XYSgEG9Kw9i2bps pgn5v4XHLW3BF4cg64vziTXqucTq+OS+W5XPFjDp1elw1j/GEqqXHJGp5mOP2qCd5eEci2ZLhAzV 9CnT4RpMmN54eOyTkdzyeAgQ8+187QssDm5QR7HHa2JEwUZ5MLBvcnh2c88AAAAAAAA= --Apple-Mail=_286DF6FB-4315-4893-89D0-D5544C1E3313-- From nobody Thu Sep 6 06:40:35 2018 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 44FA9130E61 for ; Thu, 6 Sep 2018 06:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 GET6r3r9b1Ye for ; Thu, 6 Sep 2018 06:40:31 -0700 (PDT) Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) (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 65B74130E4C for ; Thu, 6 Sep 2018 06:40:31 -0700 (PDT) Received: by mail-ed1-f48.google.com with SMTP id p52-v6so8883308eda.12 for ; Thu, 06 Sep 2018 06:40:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=5+4n8tS672EDaXBMIm0kRs/GS2bUKTDqj2/qv2NXlOA=; b=WvAjw+1ZykrWW0r1CUgqAIBTROjP/3WCzdK+4GNUL2v552GJF/XEcuQE+Xphl9TDLK S7F4VaOd6jhm8qS5n62uEh/2VYWMg7Dw3McutuXTv874RUa2yPwcRPoV/0E3zwHJ/bHf qE3O8ZY6WN1fp0Rcd3+tVpztJ9mztcV66LFRQuKinbABnUC49fbKD4ekfaY8bs9RjeQn T7zB/MatbokQLU0IoOjP7FjI8nSBdlBdSKfhBqIap0y/PR1vnvPW89CsC2a9PUowmOr/ yzo4wAJ0lxE35kwJCtApD5bjNCAfNYsZEnCvhslCnSGwVLftWN2h5P3pipLJV0KY1KQp 2kCQ== X-Gm-Message-State: APzg51BT6U1FgJinG9mrTzKykgHU6bGGQ4funoNQjFJNlZsAJkVxNWF1 Zpt9y+vsb4fVIK+a39iDnEzZrw== X-Google-Smtp-Source: ANB0VdaogkKVaahWNvwUFmsKQU4SLIuOemD6Ii5unzqknLpAbAITaEmxfW6M4jB5n9OCEd6N8C5Oug== X-Received: by 2002:a50:a93c:: with SMTP id l57-v6mr3404017edc.229.1536241229290; Thu, 06 Sep 2018 06:40:29 -0700 (PDT) Received: from localhost (hanna.meerval.net. [192.147.168.57]) by smtp.gmail.com with ESMTPSA id 25-v6sm3545677edz.45.2018.09.06.06.40.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 06:40:28 -0700 (PDT) Date: Thu, 6 Sep 2018 15:40:26 +0200 From: Job Snijders To: Daniel Kopp Cc: SIDR Operations WG Message-ID: <20180906134026.GC3097@hanna.meerval.net> References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> <20180905073454.GU3097@hanna.meerval.net> <16AB499B-D859-48D2-9C36-AAF4C6F29B1C@de-cix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16AB499B-D859-48D2-9C36-AAF4C6F29B1C@de-cix.net> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Thu, 06 Sep 2018 13:40:33 -0000 On Thu, Sep 06, 2018 at 01:21:49PM +0000, Daniel Kopp wrote: > > On 5. Sep 2018, at 09:34, Job Snijders wrote: > > > > I have to ask, (given the author's affiliations) - if this draft is > > published as an RFC, will you turn back the clock and start > > propagating invalid route announcements to your customers (marked > > with an extended community)? > > It’s not turning back the clocks. There is no origin validation at > DE-CIX yet and as far as I know, DE-CIX wanted the draft to drive the > implementation. In that case, it appears the draft has been taken over by current events? From what I understood from your organisation's communications related to deploying RPKI origin validation there has been a commitment to deploy this fall. > Moreover the draft defines the different modes of operations, so as > far as I know also AMS-IX wants to add the tagging to their current > implementation. This puzzles me - AMS-IX already implemented this, some documentation can be found here: https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers/route-server-filtering (note the 6777:65012, 6777:65022, and 6777:65023) communities. Kind regards, Job From nobody Fri Sep 7 00:17:45 2018 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 DF32A129C6A for ; Fri, 7 Sep 2018 00:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 dNN2uqpoZLwZ for ; Fri, 7 Sep 2018 00:17:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBE11286D9 for ; Fri, 7 Sep 2018 00:17:41 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local ([194.88.241.230]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w876HXht093591 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2018 07:17:33 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host [194.88.241.230] claimed to be crumpet.local To: Christopher Morrow Cc: Randy Bush , sidrops@ietf.org References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> From: Nick Hilliard Message-ID: Date: Fri, 7 Sep 2018 08:17:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Fri, 07 Sep 2018 07:17:44 -0000 Christopher Morrow wrote on 05/09/2018 17:39: > On Wed, Sep 5, 2018 at 10:56 AM Randy Bush > wrote: > "is pretty much useless" - Needs bug(s) filed and development work in > order to rectify this problem. > I'd caution against: "is useless, never talk to it again" because ... > ideally we want all the bgp software folk to do the right thing here, right? >  so ideally ov-clarify already whacks "popular hardware vendors" on the > nose, let's make sure the 'popular software vendors' also have bugs > filed against them? from the bigger picture point of view, buggy rpki implementations are irritating but implementation problems like this are not sufficient reason for the ietf to create workarounds, particularly when those workarounds require new code on router stacks, i.e. have a substantial material cost and require debugging. As an aside, router vendors have shown historically that they don't much like supporting cli glue for extended communities, so it's difficult to see how they'd write code for this. The ov-clarify draft will probably help deployment in the longer term, as it creates a tickbox which will end up on RFPs and compliance testing suites. Nick From nobody Fri Sep 7 00:23:16 2018 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 C432B129C6A for ; Fri, 7 Sep 2018 00:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VmZgGNeTYZtZ for ; Fri, 7 Sep 2018 00:23:13 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228D01286D9 for ; Fri, 7 Sep 2018 00:23:12 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from crumpet.local ([194.88.241.230]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w876N7nj094275 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2018 07:23:07 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host [194.88.241.230] claimed to be crumpet.local To: Randy Bush Cc: Christopher Morrow , SIDR Operations WG References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> From: Nick Hilliard Message-ID: <3bfa28ab-4460-ddaf-5f4a-9133b1841128@foobar.org> Date: Fri, 7 Sep 2018 08:23:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Fri, 07 Sep 2018 07:23:15 -0000 Randy Bush wrote on 05/09/2018 15:56: >> Another limitation would be that it doesn't handle aggregators as the >> last element in the as path. > > don't care. they're irrelevant. they're irrelevant until the point that they're not. I mentioned them because they crop up from time to time at IXPs, which is where you notice that your traffic routing is being handled by covering supernets rather than your more-specifics. The last ticket we had on this was earlier this summer. Nick From nobody Fri Sep 7 07:03:43 2018 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 8061A129AB8 for ; Fri, 7 Sep 2018 07:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 qXHKI5wfJDuK for ; Fri, 7 Sep 2018 07:03:38 -0700 (PDT) Received: from de-cix.net (relay3.de-cix.net [46.31.121.23]) (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 2357F130DD5 for ; Fri, 7 Sep 2018 07:03:37 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.53,342,1531778400"; d="p7s'?scan'208"; a="2380874" Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw013.de-cix.net with ESMTP; 07 Sep 2018 16:03:35 +0200 Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id E6A6DB00B8; Fri, 7 Sep 2018 16:03:33 +0200 (CEST) Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 7 Sep 2018 16:03:33 +0200 Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1367.000; Fri, 7 Sep 2018 16:03:33 +0200 From: Daniel Kopp To: Job Snijders CC: SIDR Operations WG Thread-Topic: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 Thread-Index: AQHUOie94b+qhBJXv0aVQvhLDzuGmaTL0PCAgAMH8YCAEWE/gIAA7XyAgAAYbQCAAfNFgIAABTEAgAGYyQA= Date: Fri, 7 Sep 2018 14:03:33 +0000 Message-ID: References: <20180822161549.GA1021@hanna.meerval.net> <42CA116C-4F74-4D31-A58E-3D7528FC529F@de-cix.net> <20180905073454.GU3097@hanna.meerval.net> <16AB499B-D859-48D2-9C36-AAF4C6F29B1C@de-cix.net> <20180906134026.GC3097@hanna.meerval.net> In-Reply-To: <20180906134026.GC3097@hanna.meerval.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.6.18) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.140.134] Content-Type: multipart/signed; boundary="Apple-Mail=_2B9F95D0-E75A-4C2E-9675-34C6F51695FC"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018 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: Fri, 07 Sep 2018 14:03:42 -0000 --Apple-Mail=_2B9F95D0-E75A-4C2E-9675-34C6F51695FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6. Sep 2018, at 15:40, Job Snijders wrote: >=20 > In that case, it appears the draft has been taken over by current > events? =46rom what I understood from your organisation's = communications > related to deploying RPKI origin validation there has been a = commitment > to deploy this fall. No, the draft hasn=E2=80=99t been taken over by other events.=20 The idea was to adjust the implementation according to the draft. So I don=E2=80=99t see that this draft is outdated in that sense. > This puzzles me - AMS-IX already implemented this, some documentation > can be found here: = https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-serv= ers/route-server-filtering > (note the 6777:65012, 6777:65022, and 6777:65023) communities. Yes, AMS-IX has already some flavour of implementation for that=E2=80=A6 = and one goal of the draft is to have a common and well defined way how = to implement this. Kind regards Daniel --Apple-Mail=_2B9F95D0-E75A-4C2E-9675-34C6F51695FC Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBjCCBkAw ggUooAMCAQICFHyxDwExx02H4STp1P4iVRvBZ68RMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMjAeFw0xNzExMjcxMzMyMjFaFw0yMjExMjcxMzMyMjFaMIGMMQsw CQYDVQQGEwJERTEfMB0GA1UEChMWREUtQ0lYIE1hbmFnZW1lbnQgR21iSDEfMB0GA1UECwwWUmVz ZWFyY2ggJiBEZXZlbG9wbWVudDElMCMGCSqGSIb3DQEJARYWZGFuaWVsLmtvcHBAZGUtY2l4Lm5l dDEUMBIGA1UEAxMLRGFuaWVsIEtvcHAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDk Jvo9dsDe4/cugYUYjg+L7qzCYJ2Z4OZKuzidzBMh/POQQOO/AA/pczvnkasmswAsPvESoQFih4EI 3i5VJozg81wGOSe1iDmaB8OJSyaA8dN2coOo4266Xmx7RPRvoU4cfGU+AOlYazzO76AWmMomgMc/ 7bWbuzFSB8RQ9FwVgNxqQXXIOPwYSXKA5z7f46S0uYfMxsxdf0cuwqI1uxPdKi6z+mG8MJOk7VVM Ru5eXVUSHbwCzi9aItNkHwu0kADYk9mAEY9dtuhIoE2ZgzAq0gRcEYVGpcZW8THhutqElE59z2at G9qbTIbIFkmIQUiSxkCssyKxXhViZL4PpP/pAgMBAAGjggLNMIICyTAhBgNVHREEGjAYgRZkYW5p ZWwua29wcEBkZS1jaXgubmV0MA4GA1UdDwEB/wQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDBDAd BgNVHQ4EFgQU9G9KiD0soUVY6ZoVKSASO+LMWhswHwYDVR0jBBgwFoAU8MejMpG168q1WHcVp06+ Gl1hQyUwgf8GA1UdHwSB9zCB9DBHoEWgQ4ZBaHR0cDovL2NybC5zd2lzc3NpZ24ubmV0L0YwQzdB MzMyOTFCNUVCQ0FCNTU4NzcxNUE3NEVCRTFBNUQ2MTQzMjUwgaiggaWggaKGgZ9sZGFwOi8vZGly ZWN0b3J5LnN3aXNzc2lnbi5uZXQvQ049RjBDN0EzMzI5MUI1RUJDQUI1NTg3NzE1QTc0RUJFMUE1 RDYxNDMyNSUyQ089U3dpc3NTaWduJTJDQz1DSD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jh c2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwYQYDVR0gBFowWDBWBglghXQBWQED AQYwSTBHBggrBgEFBQcCARY7aHR0cDovL3JlcG9zaXRvcnkuc3dpc3NzaWduLmNvbS9Td2lzc1Np Z24tU2lsdmVyLUNQLUNQUy5wZGYwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlhodHRw Oi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkxQjVF QkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVyLXBl cnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRF QkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQCRy7o0H3gyfjNudjAi+zZltdsfYG27vYqQ fKHl32E3J383bMIGdyhFtBv+0qtQyIsz3QZnUb8PnJ72ap2x1e3zGhw2+vbd8K/1aROe1vd0wdVG /muRCLSUPn8K2+wzAxtvAWwJRORPkeTxkiMY0Cve5n6/qigvUyvbMFCO09Mp2NHzBxqKXyI027Zy b34iKso23ycueRREdG0PNTOd/CwX3XuS/Mr2A/mmsX9B7PWdcjbaE3qOPhg1p8mp0SImPuHAl7p0 UEVDqBt4XTOKJRZv6KJD/tdIonyFQdj/FgTYncl8N7BJLwO/qHxATlmKXogdLAe6Ifyam8DHeHgK 9mUMMIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNV BAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2ZXIg Q0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNIMRUw EwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2ZXIg Q0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJobzD g6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDvALLr EzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2Yru5 aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5rgtmQ DAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kVmJyU U8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQXoM3B 5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2ln bi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCBooaB n2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIzQkNC NDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAEWjBY MFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24u Y29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYIKwYB BQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2FkLzE3 QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0dHA6 Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZB ODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkdaI3K CNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsponPe l/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZVKIh jfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0wl+S 4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8u7mO lL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQwJtE QK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/mpaG /ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8N43x Hm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4Fg9q 2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uoxggL2MIIC8gIBATBuMFYxCzAJBgNVBAYTAkNIMRUwEwYD VQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0Eg MjAxNCAtIEcyMgIUfLEPATHHTYfhJOnU/iJVG8FnrxEwCQYFKw4DAhoFAKCCAV0wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwOTA3MTQwMzMyWjAjBgkqhkiG9w0B CQQxFgQUwBcnOXiObcoErXH/GeXcxU4pYZAwfQYJKwYBBAGCNxAEMXAwbjBWMQswCQYDVQQGEwJD SDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1NpZ24gUGVyc29uYWwgU2ls dmVyIENBIDIwMTQgLSBHMjICFHyxDwExx02H4STp1P4iVRvBZ68RMH8GCyqGSIb3DQEJEAILMXCg bjBWMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMTAwLgYDVQQDEydTd2lzc1Np Z24gUGVyc29uYWwgU2lsdmVyIENBIDIwMTQgLSBHMjICFHyxDwExx02H4STp1P4iVRvBZ68RMA0G CSqGSIb3DQEBAQUABIIBAG7hMQyZ3n5tQBHT3+gStaNMWeB0w+ICUVsyxEy6c8SW1mJqY9cxOA0t oxnhFxNahygIdHE4bYJDXv/wVe5Riznt+rxL3xTpNQ5CEPOLRDAyr/yPqGQx400O5pC8gkJkU0gT KBUmm5jUFuV+kJ0Rf16WzkL0bhfI4HtKQFqxxUGQU9t6b7UuzahcWHnrOqBHvnC72NK5bVgWTwEi peHRHvILDe4byfViimqbDRNwaX3KHCRQ5z+ZXA+qwt+uwgFZUllMBkhRh/wf1ZBM/weIOiab4gQL wRDFNvXD/QLXWHKj65noKcagxydiy7sBUyPNraS2MpMYpo3PRyoguyQrfEQAAAAAAAA= --Apple-Mail=_2B9F95D0-E75A-4C2E-9675-34C6F51695FC-- From nobody Fri Sep 7 19:19:53 2018 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 CCE261294D7; Fri, 7 Sep 2018 19:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 JRJRvfOxZaVb; Fri, 7 Sep 2018 19:19:49 -0700 (PDT) Received: from limes.NIC.DTAG.DE (limes.NIC.DTAG.DE [194.25.1.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB41130DDC; Fri, 7 Sep 2018 19:19:48 -0700 (PDT) Received: from x59.NIC.DTAG.DE (x59.NIC.DTAG.DE [194.25.1.154]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id EAA00960; Sat, 8 Sep 2018 04:19:47 +0200 (MEST) To: Christopher Morrow cc: sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org From: Ruediger Volk In-Reply-To: Your message of "Wed, 22 Aug 2018 10:52:02 EDT." Date: Sat, 08 Sep 2018 04:19:47 +0200 Message-ID: <20212.1536373187@x59.NIC.DTAG.DE> Archived-At: Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker 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: Sat, 08 Sep 2018 02:19:52 -0000 > Howdy WG folk! > The authors of: draft-ietf-sidrops-validating-bgp-speaker > are thinking their draft is ready to move forward, there hasn't been > significant conversation about this document since the last meeting in > Montreal... so: I believe this looked much more innocent (just the document name?) at the adoption call (and slipped under my radar - like too many things). This draft is not acceptable for a number (>1) of reasons. The primary being: it introduces security problems by carrying security information over uncontrolled paths without securing authenticity. By choosing extended community as the container for the unauthenticated information the problem is made worse, because for a long time we cannot assume that operator will have methods operational for controlling propagation of that unauthenticated security information; and the draft does not seem to propose or consider any methods and practices for controlling and limiting propagation - except . To illustrate the class of problem I give an example: I'm operating AS64510. Anybody connected to the global BGP can inject routes with the proposed extended community or (using special hacked BGP) the extended community to routes it propagates indicating whatever validation state suits their purpose and indicate that high reputation AS64510 is source of the validation state. Now AS64510 does not even has a way diagnosing presence or removing of that fake information; note: for handling extended communities vendors actually have to spin code - even to support generic policy primitives such as delete or match (as a decision criterium). The security considerations are certainly seriously incomplete. Explicit and prominent note of transitive propagation of unauthenticated security information MUST be added (even a reference to general BGP security analysis that warns about missing authencation and authenticity of BGP routes and attributes is missing!). Some consideration of the trust relations involved with signaling the extended community or using it as a relying party in local policy would be needed. >From that point of view it looks strange that no mention of the relying party controlling which source over which path it trusts. While searching through the document for the security handling I came across quite some spots that looked like somewhat fuzzy in terminology or otherwise lacking - not ready for publication. In some protocol proposals it is a good idea to clearly identify the functions of implementations that need configuration, and whether the default should be ON or OFF. Here it quite definitely ought to be default OFF! I believe the draft should be declared dead; perhaps after a final spin that inserts a security warning.. Discussion of requirements and reasonable approaches to reduce operational burden of origin validation may be needed. However this draft not help for that! The basic signal flow idea of this draft could be handled easily in already available/deployed router software with user configured policy with much better control; someone desperate could be using it in a months time ./. waiting more than a year for new router software version. + we should help the vendors to focus on fixing and completing the standard RPKI OV functionality (think clarify-ov) and avoid diverting energy and attention to another new feature. Different approaches to outsourcing of the security function may be more secure and much easier to configure. Documenting a solution obviously would be helpful to some and could help to avoid some bad security designs. Ruediger Volk From nobody Fri Sep 14 02:59:01 2018 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 70575130DD6 for ; Fri, 14 Sep 2018 02:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no autolearn_force=no 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 P6XIkO1f01Ff for ; Fri, 14 Sep 2018 02:58:58 -0700 (PDT) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (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 99F6B130DC9 for ; Fri, 14 Sep 2018 02:58:57 -0700 (PDT) Received: by mail-ed1-f52.google.com with SMTP id p52-v6so6931085eda.12 for ; Fri, 14 Sep 2018 02:58:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=jjFYnpQhF6iPwzfQKZhphGPV46AN/wYrJQUBsh1rAns=; b=tjmVnaPUicHUTqttz2AunNz83Da7c4V/rAf30/MrH8iqAb/WwHuWneQOdXWHrXz8zv 4ue8PBzunapGiUUT7+TMhxIdAeqNWBkd8/zN3EZm5B/bsS5MhvrRTDt/3jTolK6kUt0u XHB+/+B1hRQ3fu95bHhy6J8ea9otoSrtfu0P4uEZqUl/k5HeBnY4SfIpu031mSxxtXcQ wOz1dSjTCDw/EHzX2g9WhYUo5g4tRk06ATZL0xlMAyeTeEeUEYQ/Tsg/CLAspr2cZrUj mo3SjQ9EJ5psNyVKP9VdZpmkthYbjBy0NMPBYu33qrwNYqkueDAPqJ/Os9tV3hAiSCnr Dy1w== X-Gm-Message-State: APzg51CgKBGA1xrV//14z7QtTV2ZQyKDfLeocNiLPwzNjytQecYsLZDv 1caqkWIx9wYQFpYsL+SUG3OHXhO5Kf0= X-Google-Smtp-Source: ANB0VdY1HF+no+tuNgBx9OhpjALbC3u2oxhBufHjG96V/GR5mxU5gf/3CoyvlqGGnIEbHUCK2ATSdA== X-Received: by 2002:a50:8b25:: with SMTP id l34-v6mr18741148edl.265.1536919135351; Fri, 14 Sep 2018 02:58:55 -0700 (PDT) Received: from localhost (hanna.meerval.net. [192.147.168.57]) by smtp.gmail.com with ESMTPSA id w20-v6sm5920149edc.12.2018.09.14.02.58.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 02:58:54 -0700 (PDT) Date: Fri, 14 Sep 2018 11:58:53 +0200 From: Job Snijders To: sidrops@ietf.org Message-ID: <20180914095853.GO1174@hanna.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Sidrops] NLNOG 2018 RPKI talks 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: Fri, 14 Sep 2018 09:59:00 -0000 Hi folks, This may be of interest to some of you. At the last NLNOG meeting quite some attention was given to the topic of routing security, specifically RPKI. "Routinator 3000" - https://www.youtube.com/watch?v=x2hhtvsfMgM "RPKI For Managers" - https://www.youtube.com/watch?v=vrzl__yGqLE "Measuring RPKI Adoption via the data-plane" - https://www.youtube.com/watch?v=uDIQDpGObdc "Routing Security Roadmap" - https://www.youtube.com/watch?v=3BAwBClazWc slides available here: https://nlnog.net/nlnog-day-2018/ Kind regards, Job From nobody Sun Sep 16 16:14:38 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BF8130E06; Sun, 16 Sep 2018 16:14:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153713967631.17006.4084016061719321644@ietfa.amsl.com> Date: Sun, 16 Sep 2018 16:14:36 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-tree-validation-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2018 23:14:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator Authors : Oleg Muravskiy Tim Bruijnzeels Filename : draft-ietf-sidrops-rpki-tree-validation-03.txt Pages : 16 Date : 2018-09-16 Abstract: This document describes the approach to validate the content of the RPKI certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism. This allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol, and repositories that use a mix of both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-tree-validation-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-tree-validation-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 16 16:25:07 2018 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 70072128C65; Sun, 16 Sep 2018 16:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yDWdsD3lZ7nF; Sun, 16 Sep 2018 16:25:03 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 DDCE7126BED; Sun, 16 Sep 2018 16:25:02 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1g1gPV-000BWF-GP; Mon, 17 Sep 2018 01:25:01 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::20]) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1g1gPU-00047B-6Z; Mon, 17 Sep 2018 01:25:00 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_B4095734-EC9A-436D-A9CC-4EAE4D1528F5" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Oleg Muravskiy In-Reply-To: <153713967631.17006.4084016061719321644@ietfa.amsl.com> Date: Mon, 17 Sep 2018 01:24:59 +0200 Cc: sidrops-chairs@ietf.org, IETF Secretariat Message-Id: <93DC2A4D-F63B-4988-ABD5-E4492EB4878A@ripe.net> References: <153713967631.17006.4084016061719321644@ietfa.amsl.com> To: sidrops@ietf.org X-Mailer: Apple Mail (2.3445.9.1) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b745f2000d6cafce9c71c6a4420903412b9 Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-tree-validation-03.txt 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: Sun, 16 Sep 2018 23:25:06 -0000 --Apple-Mail=_B4095734-EC9A-436D-A9CC-4EAE4D1528F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This version resolves issues discussed during the IESG review. > On 17 Sep 2018, at 01:14, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : RPKI Certificate Tree Validation by the RIPE = NCC RPKI Validator > Authors : Oleg Muravskiy > Tim Bruijnzeels > Filename : draft-ietf-sidrops-rpki-tree-validation-03.txt > Pages : 16 > Date : 2018-09-16 >=20 > Abstract: > This document describes the approach to validate the content of the > RPKI certificate tree, as it is implemented in the RIPE NCC RPKI > Validator. This approach is independent of a particular object > retrieval mechanism. This allows it to be used with repositories > available over the rsync protocol, the RPKI Repository Delta > Protocol, and repositories that use a mix of both. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-tree-validat= ion-03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rpki-tree-validatio= n-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops >=20 --Apple-Mail=_B4095734-EC9A-436D-A9CC-4EAE4D1528F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = version resolves issues discussed during the IESG review.

On 17 = Sep 2018, at 01:14, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the SIDR Operations WG of the IETF.

=        Title =           : RPKI = Certificate Tree Validation by the RIPE NCC RPKI Validator
=        Authors =         : Oleg Muravskiy
=             &n= bsp;           &nbs= p;Tim Bruijnzeels
Filename =        : = draft-ietf-sidrops-rpki-tree-validation-03.txt
Pages =           : 16
= Date =            : = 2018-09-16

Abstract:
=   This document describes the approach to validate the content = of the
  RPKI certificate tree, as it is = implemented in the RIPE NCC RPKI
  Validator. =  This approach is independent of a particular object
=   retrieval mechanism.  This allows it to be used with = repositories
  available over the rsync = protocol, the RPKI Repository Delta
  Protocol, = and repositories that use a mix of both.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-v= alidation/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-valida= tion-03
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-t= ree-validation-03

A diff from the previous = version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rpki-tre= e-validation-03


Please note = that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

= --Apple-Mail=_B4095734-EC9A-436D-A9CC-4EAE4D1528F5-- From nobody Mon Sep 17 13:40:45 2018 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 15BFE130DCE; Mon, 17 Sep 2018 13:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 d9ete_i45SCO; Mon, 17 Sep 2018 13:40:36 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 71B1D124D68; Mon, 17 Sep 2018 13:40:36 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1g20Jp-00085I-Vl; Mon, 17 Sep 2018 22:40:29 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::136]) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1g20Jo-0003cB-M0; Mon, 17 Sep 2018 22:40:28 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_45635868-E7FC-41B4-9C2E-F4F93D41C187" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Oleg Muravskiy In-Reply-To: <20180905212251.GF73164@kduck.kaduk.org> Date: Mon, 17 Sep 2018 22:40:27 +0200 Cc: Chris Morrow , sidrops-chairs@ietf.org, sidrops@ietf.org, The IESG , draft-ietf-sidrops-rpki-tree-validation@ietf.org Message-Id: <226E16D0-3CB0-49D3-9229-1535A6C9FA50@ripe.net> References: <153547412129.23827.3324575091222487462.idtracker@ietfa.amsl.com> <4A92D060-389A-4104-A7CF-49984773596B@ripe.net> <20180904170806.GI91593@kduck.kaduk.org> <20180905212251.GF73164@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) X-ACL-Warn: Delaying message X-RIPE-Signature: c408758d4ce2e8eb06762a65a3365b749034e524b1adbee8e6b7057778c4eb8d Archived-At: Subject: Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rpki-tree-validation-02: (with COMMENT) 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: Mon, 17 Sep 2018 20:40:39 -0000 --Apple-Mail=_45635868-E7FC-41B4-9C2E-F4F93D41C187 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 5 Sep 2018, at 23:22, Benjamin Kaduk wrote: >=20 > On Wed, Sep 05, 2018 at 09:56:46AM +0200, Oleg Muravskiy wrote: >> HI Benjamin, >>=20 >>> On 4 Sep 2018, at 19:08, Benjamin Kaduk wrote: >>>=20 >>> On Mon, Sep 03, 2018 at 12:19:38AM +0200, Oleg Muravskiy wrote: >>>> Hi Benjamin, >>>>=20 >>>> Thanks for your comments. I am updating the draft, please see my = inline comments below: >>>>=20 >>>>> On 28 Aug 2018, at 18:35, Benjamin Kaduk wrote: >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> This document is Informational, so I will make my comments = non-blocking, >>>>> but I think that the security considerations could be improved. = It >>>>> currently does a good job talking about cases where the procedure = can >>>>> receive inconsistent inputs (and how it behaves in the face of = those >>>>> inputs), as well as some other considerations, and this is great! = I think >>>>> that the discussion could be more powerful if it also considered = how those >>>>> inconsistent inputs could be produced, in particular which = capabilities an >>>>> attacker could have. There seem to be roughly three classes of = actors for >>>>> active attacks -- an attacker in the network could modify the = transferred >>>>> content (including number of files and directory layout) over = unecrypteed >>>>> rsync or http, an attacker that compromises the webserver's = certificate >>>>> (or obtains a fraudulent one) could do the same over encrypted = https, and >>>>> an attacker that compromises the TA signing key could produce >>>>> fake-but-"valid" manifests, CRLs, etc.. (Is there more that could = be done >>>>> with a compromised non-TA CA? The potential hazards to this = algorithm >>>>> don't seem to be noticably distinct, though.) Some consumers may = be >>>>> willing to trust in the TA's integrity or even the Web PKI and not = worry >>>>> about those risks. Though there is always risk of accidental = error, of >>>>> course, and the current coverage in this document seems adequate = for that >>>>> risk. >>>>=20 >>>> In the Security Considerations we tried to describe issues specific = to our implementation. >>>> What you suggest seems to be a general discussion of = vulnerabilities in the RPKI repository architecture that is defined by = current standards. I agree that it is missing in the current set of RFCs = and it would be great to have it, but on the other hand I do not think = it should be done it this document. It would also require another round = of going through the WG discussion, I believe. So I left this section as = is. >>>=20 >>> I can't fault you for that. Do you think there is any energy to put = into a >>> standalone document that covers these topics? >>=20 >> Maybe :) >=20 > I'd be happy to see one, though I probably could not be the driving = force > myself. >=20 >>>>> 4. Perform manifest entries discovery and validation as described = in >>>>> Section 4.2.2. >>>>>=20 >>>>> nit: "manifest entry discovery" (singular "entry=E2=80=9D) >>>>=20 >>>> The manifest contains an entry per object in the publication point, = so there are at least 2 entries =E2=80=93 for a CA cert and a manifest. >>>> I guess plural =E2=80=9Centries=E2=80=9D is appropriate here. >>>=20 >>> Ah. I would suggest "discovery of manifest entries", then, though = of >>> course the RFC Editor would probably have some suggestsions as well. >>=20 >> Sounds good >>=20 >>>>> Section 5.1.1, 5.1.2 >>>>>=20 >>>>> The syntactic verification performed here is done on what should = be >>>>> considered "untrusted input", which means that the verification = code needs >>>>> to be written in a robust manner. (Given the historical = recurrences of, >>>>> e.g., ASN.1 decoder security vulnerabilities, we probably need to >>>>> explicitly state this in the security considerations.) >>>>=20 >>>> Well, I could say that the validation =E2=80=9Cis written and = performed in a robust manner=E2=80=9D, but I do not see how this will = improve the content... >>>=20 >>> I was thinking more along the lines of a note in the security >>> considerations: "The syntactic validation steps performed in = Sections 5.1.1 >>> and 5.1.2 are operating on untrusted input, so particular care = should be >>> taken to avoid buffer overflows and similar attacks." But this is = just a >>> suggestion and I won't be offended if you decide to not use it. >>=20 >> Well, this document describes the existing implementation, not how it = should be done. >> But there is https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/, = I think it would fit there quite well. >=20 > Fair enough. Do I need to send mail or make a pull request or = anything > like that, or are the wheels already moving on this one? There=E2=80=99s been a call for input: = https://mailarchive.ietf.org/arch/msg/sidrops/zs0-pbiIVzeuhINRbYuBBpXhLME >>> Section 9.1 >>>=20 >>> If I understand correctly, RFC 6485 allows for (and predicts the = need for) >>> hash agility in the file hash algorithm. In this case, it would = probably >>> be appropriate to say something about how "the security of the = system as a >>> whole is limited to that of the weakest hash function allowed by = consumers, >>> but the hash agility provided for by RFC 6485 allows new (stronger) = hashes >>> to be introduced and old hash functions phased out before they are >>> critically broken=E2=80=9D. >>> Allowing untrusted data that is not authenticated (e.g., by a = digital >>> signature) to overwrite existing data in the store that has been >>> authenticated, is something I would not want to see in an IETF = protocol. >>> It would only be allowed after the latest manifest has been = authenticated >>> and fully processed, and when the "old" resource is no longer = referenced by >>> the manifest. This is a matter of the order of operations for = processing, >>> more than a perceived requirement to retain an "old" object that is = no >>> longer referenced. But, since we are not objecting to the current = text, >>> feel free to ignore this discussion point. >>=20 >> OK, thanks for your input. >> I do agree with that, and I think it would not be difficult to fix it = in our code and make a maintenance release. I made changes to our code and the new release will come soon. So I = removed this section from the -03 version of the draft. Cheers, Oleg --Apple-Mail=_45635868-E7FC-41B4-9C2E-F4F93D41C187 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 5 Sep 2018, at 23:22, Benjamin Kaduk <kaduk@mit.edu> wrote:

On Wed, Sep = 05, 2018 at 09:56:46AM +0200, Oleg Muravskiy wrote:
HI = Benjamin,

On 4 Sep 2018, at 19:08, Benjamin Kaduk <kaduk@mit.edu> wrote:

On Mon, Sep 03, 2018 at 12:19:38AM +0200, Oleg = Muravskiy wrote:
Hi = Benjamin,

Thanks for your comments. I am = updating the draft, please see my inline comments below:
On 28 Aug 2018, at = 18:35, Benjamin Kaduk <kaduk@mit.edu> wrote:
---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

This document is Informational, so = I will make my comments non-blocking,
but I think that the = security considerations could be improved.  It
currently does a good job talking about cases where the = procedure can
receive inconsistent inputs (and how it = behaves in the face of those
inputs), as well as some = other considerations, and this is great!  I think
that = the discussion could be more powerful if it also considered how those
inconsistent inputs could be produced, in particular which = capabilities an
attacker could have.  There seem to = be roughly three classes of actors for
active attacks -- = an attacker in the network could modify the transferred
content (including number of files and directory layout) over = unecrypteed
rsync or http, an attacker that compromises = the webserver's certificate
(or obtains a fraudulent one) = could do the same over encrypted https, and
an attacker = that compromises the TA signing key could produce
fake-but-"valid" manifests, CRLs, etc..  (Is there more = that could be done
with a compromised non-TA CA?  The = potential hazards to this algorithm
don't seem to be = noticably distinct, though.)  Some consumers may be
willing to trust in the TA's integrity or even the Web PKI = and not worry
about those risks.  Though there is = always risk of accidental error, of
course, and the = current coverage in this document seems adequate for that
risk.

In the = Security Considerations we tried to describe issues specific to our = implementation.
What you suggest seems to be a general = discussion of vulnerabilities in the RPKI repository architecture that = is defined by current standards. I agree that it is missing in the = current set of RFCs and it would be great to have it, but on the other = hand I do not think it should be done it this document. It would also = require another round of going through the WG discussion, I believe. So = I left this section as is.

I = can't fault you for that.  Do you think there is any energy to put = into a
standalone document that covers these topics?

Maybe :)

I'd be happy to see one, though I probably could not be the = driving force
myself.

4.  Perform manifest entries discovery and validation as = described in
    Section 4.2.2.

nit: "manifest entry discovery" (singular = "entry=E2=80=9D)

The manifest = contains an entry per object in the publication point, so there are at = least 2 entries =E2=80=93 for a CA cert and a manifest.
I = guess plural =E2=80=9Centries=E2=80=9D is appropriate here.

Ah.  I would suggest = "discovery of manifest entries", then, though of
course = the RFC Editor would probably have some suggestsions as well.

Sounds good

Section 5.1.1, 5.1.2

The syntactic verification performed here is = done on what should be
considered "untrusted input", which = means that the verification code needs
to be written in a = robust manner.  (Given the historical recurrences of,
e.g., ASN.1 decoder security vulnerabilities, we probably = need to
explicitly state this in the security = considerations.)

Well, I could = say that the validation =E2=80=9Cis written and performed in a robust = manner=E2=80=9D, but I do not see how this will improve the = content...

I was thinking more = along the lines of a note in the security
considerations: =  "The syntactic validation steps performed in Sections 5.1.1
and 5.1.2 are operating on untrusted input, so particular = care should be
taken to avoid buffer overflows and similar = attacks."  But this is just a
suggestion and I won't = be offended if you decide to not use it.

Well, this document describes the existing implementation, = not how it should be done.
But there is https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/, = I think it would fit there quite well.

Fair enough.  Do I need to = send mail or make a pull request or anything
like that, or are the wheels = already moving on this one?



Section = 9.1

If I understand correctly, RFC 6485 = allows for (and predicts the need for)
hash agility in the = file hash algorithm.  In this case, it would probably
be appropriate to say something about how "the security of = the system as a
whole is limited to that of the weakest = hash function allowed by consumers,
but the hash agility = provided for by RFC 6485 allows new (stronger) hashes
to = be introduced and old hash functions phased out before they are
critically broken=E2=80=9D.

Allowing untrusted data = that is not authenticated (e.g., by a digital
signature) = to overwrite existing data in the store that has been
authenticated, is something I would not want to see in an = IETF protocol.
It would only be allowed after the latest = manifest has been authenticated
and fully processed, and = when the "old" resource is no longer referenced by
the = manifest.  This is a matter of the order of operations for = processing,
more than a perceived requirement to retain an = "old" object that is no
longer referenced.  But, = since we are not objecting to the current text,
feel free = to ignore this discussion point.

OK, thanks for your input.
I do agree with = that, and I think it would not be difficult to fix it in our code and = make a maintenance release.

I made changes to our code and the new release = will come soon. So I removed this section from the -03 version of the = draft.

Cheers,
Oleg

= --Apple-Mail=_45635868-E7FC-41B4-9C2E-F4F93D41C187-- From nobody Mon Sep 17 15:19:10 2018 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 DBC9E1294D7 for ; Mon, 17 Sep 2018 15:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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.20150623.gappssmtp.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 F8BHeSmUwu1Y for ; Mon, 17 Sep 2018 15:17:15 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 E2A1C130DDD for ; Mon, 17 Sep 2018 15:17:14 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id n2-v6so18894348wrw.7 for ; Mon, 17 Sep 2018 15:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V7yThpstD7BQ8P4adTkDLmlkXlS9+D0sdSz/vlSWSOk=; b=ll6Z6TdGymfaENiutsnBDIh9KV+X42uhd2Oc3SpxJ596qofDzMKNVVbnGO1og4sEpa pNxkCynAEC8+b3Vx6SvRvEn7QpVNxBkBiFQdyiyIsaGg+EO/+mBH0REaSqZdFyIHaoU+ WY3kyQtEb1E6uICM36djcMmPnF5wIaDGOdny+T7dfEbzUfOWexWH105eWSqiAUYmIOxR HN4OM0TYz5yDNCV1TqMzgNYXGKlVLkaDpt48hyraWLMG2JNPRBDfIS5EfWjnwOJH6Fg4 ytPnsAh5t090ZMnoGNe7z66pLi8Xq4oiSltXuNOkmugjWChC1A49KSUieOzcUxDaIoad eF8Q== 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=V7yThpstD7BQ8P4adTkDLmlkXlS9+D0sdSz/vlSWSOk=; b=gHcZl3MHHxqnIeeNia7MVxNC/928l2aduMC5X2srsjXAt+4w3v4QupzJFvPet57Jzv Ib+2Q7t9JPEk8zp93CixtPT6jHKytdSaPvXsThZX+Im3G3XPCtqs5nqOc7J+tIAPZf3+ apl16uq5TdYGBNIfw15KrByUVt4MtnWKTg5899nITI8eZPVgg4v7USkc7InkP6AhRpBT vVN/x/48Wp/IeaG48e+0fS0PhF7Yh1/oKQgXuOvO+DRV1Dj0Nbq2jmroKp5ndpIooICG 5D6NfSn+mhZZviTNau+DXLwIVG9YvWc0irH9fAiZucEter112wCEArLm0Z3XZEuTztz4 dAOw== X-Gm-Message-State: APzg51C+G32XC769TqMo4EvYwc+q7Etg+vS6TUI/xNk03PerF7gSBXXl WcZajQI4yQAxmAOAB0jYs3eH4poAI0RJvAj8TkVYLJhZwf8= X-Google-Smtp-Source: ANB0VdY+w0G+ehDRHED+6bc0inC8VJt5FvOv1RRfamv6LFSbHsINNi8CsiR68I432PSE8mHEg8UNrGw+ZDg0QWWvI6s= X-Received: by 2002:a5d:608b:: with SMTP id w11-v6mr21586170wrt.193.1537222632940; Mon, 17 Sep 2018 15:17:12 -0700 (PDT) MIME-Version: 1.0 References: <153713967631.17006.4084016061719321644@ietfa.amsl.com> <93DC2A4D-F63B-4988-ABD5-E4492EB4878A@ripe.net> In-Reply-To: <93DC2A4D-F63B-4988-ABD5-E4492EB4878A@ripe.net> From: Warren Kumari Date: Mon, 17 Sep 2018 18:16:36 -0400 Message-ID: To: oleg@ripe.net Cc: sidrops@ietf.org, SIDROps Chairs , IETF Secretariat Content-Type: multipart/alternative; boundary="000000000000fa427705761888df" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-tree-validation-03.txt 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: Mon, 17 Sep 2018 22:17:18 -0000 --000000000000fa427705761888df Content-Type: text/plain; charset="UTF-8" ... and I just approved it. Thank you authors and the WG for writing / reviewing this. I personally think that documents like this are useful to help implementers. W On Sun, Sep 16, 2018 at 7:25 PM Oleg Muravskiy wrote: > This version resolves issues discussed during the IESG review. > > On 17 Sep 2018, at 01:14, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : RPKI Certificate Tree Validation by the RIPE NCC > RPKI Validator > Authors : Oleg Muravskiy > Tim Bruijnzeels > Filename : draft-ietf-sidrops-rpki-tree-validation-03.txt > Pages : 16 > Date : 2018-09-16 > > Abstract: > This document describes the approach to validate the content of the > RPKI certificate tree, as it is implemented in the RIPE NCC RPKI > Validator. This approach is independent of a particular object > retrieval mechanism. This allows it to be used with repositories > available over the rsync protocol, the RPKI Repository Delta > Protocol, and repositories that use a mix of both. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03 > > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-tree-validation-03 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-tree-validation-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000fa427705761888df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
... and I just approved it.=C2=A0

Thank you authors and th= e WG for writing / reviewing this.=C2=A0
I personally think that documents = like this are useful to help implementers.

W

On Sun, Sep 16, 2018 at 7:25 PM Oleg Mura= vskiy <oleg@ripe.net> wrote:
=
This version resolves issues discussed during th= e=C2=A0IESG=C2=A0r= eview.

On 17 Sep 2018, at 01:14,= internet-dra= fts@ietf.org wrote:


A New Internet-Draft is available from the on-= line Internet-Drafts directories.
This draft is a work item of the SIDR = Operations WG of the IETF.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: RPKI= Certificate Tree Validation by the RIPE NCC RPKI Validator
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0: Oleg Muravskiy
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Tim Bruijnzeels
File= name =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: draft-ietf-sidrops-rpki-tr= ee-validation-03.txt
Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 16
Date =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018-09-16

A= bstract:
=C2=A0=C2=A0This document describes the approach to validate t= he content of the
=C2=A0=C2=A0RPKI certificate tree, as it is implement= ed in the RIPE NCC RPKI
=C2=A0=C2=A0Validator.=C2=A0 This approach is i= ndependent of a particular object
=C2=A0=C2=A0retrieval mechanism.=C2= =A0 This allows it to be used with repositories
=C2=A0=C2=A0available o= ver the rsync protocol, the RPKI Repository Delta
=C2=A0=C2=A0Protocol,= and repositories that use a mix of both.


The IETF datatracker s= tatus page for this draft is:
https://datat= racker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/

The= re are also htmlized versions available at:
ht= tps://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03https://datatracker.ietf.org/doc/html/= draft-ietf-sidrops-rpki-tree-validation-03

A diff from the previ= ous version is available at:
https://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-rpki-tree-validation-03

Please note that it may take a couple of minutes from the time of= submission
until the htmlized version and diff are available at tools.ietf.org.

Int= ernet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-= drafts/

_______________________________________________
Sidro= ps mailing list
Si= drops@ietf.org
https://www.ietf.org/mailman/listinfo/sidrops

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


--
I don't t= hink the execution is relevant when it was obviously a bad idea in the firs= t place.
This is like putting rabid weasels in your pants, and later exp= ressing regret at having chosen those particular rabid weasels and that pai= r of pants.
=C2=A0 =C2=A0---maf
--000000000000fa427705761888df-- From nobody Tue Sep 18 11:19:15 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A19129C6A; Tue, 18 Sep 2018 11:19:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Cc: morrowc@ops-netman.net, The IESG , sidrops@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , rfc-editor@rfc-editor.org, warren@kumari.net, draft-ietf-sidrops-rpki-tree-validation@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153729474081.8621.16418604920848045876.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2018 11:19:00 -0700 Archived-At: Subject: [Sidrops] Document Action: 'RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator' to Informational RFC (draft-ietf-sidrops-rpki-tree-validation-03.txt) X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2018 18:19:01 -0000 The IESG has approved the following document: - 'RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator' (draft-ietf-sidrops-rpki-tree-validation-03.txt) as Informational RFC This document is the product of the SIDR Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-tree-validation/ Technical Summary This document describes the approach to validate the content of the RPKI certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism. This allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol, and repositories that use a mix of both. This document describes how the RIPE NCC RPKI Validator version 2.23 has been implemented. Source code to this software can be found at [github]. The purpose of this document is to provide transparency to users of (and contributors to) this software tool, as well as serve to be subjected to scrutiny by the SIDR Operations Working Group. It is not intended as a document that describes a standard or best practices on how validation should be done in general. Working Group Summary No particularly difficult notes from the WG, this document describes the operations of a particular piece of infrastructure, it's not changing live things. Document Quality "Are there existing implementations of the protocol? " Yup, that's the whole purpose of this document :-). It is an Informational specification, "published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process". There are 3 outdated references, which can be handled by the RFC Editor: draft-ietf-sidr-delta-protocol -> RFC 8182 draft-ietf-sidr-rpki-validation-reconsidered -> RFC 8360 RFC 6485, obsoleted by RFC 7935 Personnel Chris Morrow is DS Warren Kumari is RAD (that *never* gets old!) From nobody Tue Sep 18 23:46:47 2018 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 6174912008A; Tue, 18 Sep 2018 23:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 X9wPello6wvY; Tue, 18 Sep 2018 23:17:27 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 DFC39130DD1; Tue, 18 Sep 2018 23:17:25 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id b78-v6so898006vka.12; Tue, 18 Sep 2018 23:17:25 -0700 (PDT) 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=e43OY6ZQ8S5p2EB4WTxI3etJAI9xRkU8oUAuFZlV8AI=; b=e6zVzY5exzL8tPNgh4TxHkwZawy5i2qtz8a6c2kvyKYOhK36aAYZfaGLsef1bCJHYM RYZ/Gz1mdCCbOhUpcYSC+iG8ebCKlEO1pEzvvUasna1SlJ/fCkxBlTrz4J2g8Dta69Hw dQ/MuoeAkI/mn56hScAjFOsLc31UIujrZXN5SK1On7W3GzZe4Ihk43PJvJjNx/hdHYtW 0++eZtSuj8BXNf3otPWvGQx0yFYU6oNQ8CGw8DVSU0Roc6zsYdVWKDl6PhSJxddJS1td 6QSpmkM7g+3ODuAjrsZgV/8/P1Luh9UmAnQDPluQoVpXlzSg1sNN+tnP3c+oBouIuYaK 2WOg== 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=e43OY6ZQ8S5p2EB4WTxI3etJAI9xRkU8oUAuFZlV8AI=; b=i1p4TImY8YzyF+uINgecQpRYy8gFn0+2uwvZ5VVaeLGcWICc4pCATBXvFIdPZDwV54 NcNvYXJoYmeXc6Q6jfP7Zz0NrFgXm1vKDB5T69tSKgQTVwlC5xnAR4PF8vM+EK/T3lul lErPW/eNXIw5TqG4swQ+by8u8H2NJxHSE3MJmvHDAw3ErlYQVgPPSOZzqzOH2DeMM73k PHtbFX7GilJkwjL9NjBdYeOLXlgKYRKPiWP5rHD0VIDXl4KIo+myLXqiIKZwnxpxxv9w Vy+X1dNJOWD9PpEnBosSKs21eecvq6wLCFPrgBOiXJ8xu/VYuUpoXWoEXyxH+/xBFqqY tTLA== X-Gm-Message-State: APzg51AuZTXSR/1AFVqMnirB+6J9SqpPAJUlm7P7pnFhGhSMcscGmYbE bD1xEqpndlcHfn9pY3kW/wEkBma5zE/trgnC/vAorQ== X-Google-Smtp-Source: ANB0VdZvlYduyu27N3RRhvSJ45rRhzPHck78zP/On/PrYurJomyXGfH3fz6TXMoP3fGAgu9RcC8Fk04fgUi/bnDbyes= X-Received: by 2002:a1f:7c07:: with SMTP id x7-v6mr8385020vkc.52.1537337844698; Tue, 18 Sep 2018 23:17:24 -0700 (PDT) MIME-Version: 1.0 References: <153565372581.3144.14852530580888223510@ietfa.amsl.com> <79C7E169-D962-4328-84DD-C668DD3AA1D1@sn3rd.com> In-Reply-To: <79C7E169-D962-4328-84DD-C668DD3AA1D1@sn3rd.com> From: Christopher Morrow Date: Tue, 18 Sep 2018 23:17:08 -0700 Message-ID: To: Sean Turner , sidrops@ietf.org, sidrops-chairs@ietf.org, sidrops-ads@ietf.org Cc: sidr@ietf.org Content-Type: multipart/alternative; boundary="0000000000002212f50576335cf0" Archived-At: X-Mailman-Approved-At: Tue, 18 Sep 2018 23:46:47 -0700 Subject: Re: [Sidrops] [sidr] I-D Action: draft-ietf-sidr-rtr-keying-16.txt 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: Wed, 19 Sep 2018 06:17:29 -0000 --0000000000002212f50576335cf0 Content-Type: text/plain; charset="UTF-8" Howdy sidrops folks, this document was left hanging in SIDR, it probably was better fit to sidr-ops, so let's get Sean to re-spin a re-named document, auto-adopt that and chat up any changes/etc between now and 'meeting time' ? Ideally we can turn around after the meeting breaks and WGLC this document in SIDROPS, unless changes are requested (of course!) :) thanks! -chris On Thu, Aug 30, 2018 at 11:30 AM Sean Turner wrote: > This version I believes addresses the two outstanding issues Sandy raised > during her review. > > spt > > > On Aug 30, 2018, at 14:28, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Secure Inter-Domain Routing WG of the > IETF. > > > > Title : Router Keying for BGPsec > > Authors : Randy Bush > > Sean Turner > > Keyur Patel > > Filename : draft-ietf-sidr-rtr-keying-16.txt > > Pages : 18 > > Date : 2018-08-30 > > > > Abstract: > > BGPsec-speaking routers are provisioned with private keys in order to > > sign BGPsec announcements. The corresponding public keys are > > published in the global Resource Public Key Infrastructure, enabling > > verification of BGPsec messages. This document describes two methods > > of generating the public-private key-pairs: router-driven and > > operator-driven. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-16 > > https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-16 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-16 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --0000000000002212f50576335cf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy sidrops folks, this document was left hanging in SID= R, it probably was better fit to sidr-ops, so let's get Sean to re-spin= a re-named document, auto-adopt that and chat up any changes/etc between n= ow and 'meeting time' ?

Ideally we can turn arou= nd after the meeting breaks and WGLC this document in SIDROPS, unless chang= es are requested (of course!) :)

thanks!
-chris

On T= hu, Aug 30, 2018 at 11:30 AM Sean Turner <sean@sn3rd.com> wrote:
T= his version I believes addresses the two outstanding issues Sandy raised du= ring her review.

spt

> On Aug 30, 2018, at 14:28, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Secure Inter-Domain Routing WG of the= IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Router Keying for BGPsec
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Randy Bush
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Sean Turner
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Keyur Patel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-sidr-rtr-keying-16.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 18
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-08-30
>
> Abstract:
>=C2=A0 =C2=A0BGPsec-speaking routers are provisioned with private keys = in order to
>=C2=A0 =C2=A0sign BGPsec announcements.=C2=A0 The corresponding public = keys are
>=C2=A0 =C2=A0published in the global Resource Public Key Infrastructure= , enabling
>=C2=A0 =C2=A0verification of BGPsec messages.=C2=A0 This document descr= ibes two methods
>=C2=A0 =C2=A0of generating the public-private key-pairs: router-driven = and
>=C2=A0 =C2=A0operator-driven.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/dr= aft-ietf-sidr-rtr-keying/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf= -sidr-rtr-keying-16
> https://datatracker.ietf.org= /doc/html/draft-ietf-sidr-rtr-keying-16
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-sidr-rtr-keying-16
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--0000000000002212f50576335cf0-- From nobody Wed Sep 19 11:41:00 2018 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 6CF07127B92 for ; Wed, 19 Sep 2018 11:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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.20150623.gappssmtp.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 IDWOwGPcYa3B for ; Wed, 19 Sep 2018 11:40:55 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 EFFE31310C2 for ; Wed, 19 Sep 2018 11:40:52 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 207-v6so8076667wme.5 for ; Wed, 19 Sep 2018 11:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZT1ovF4Qq8SlLHEg4jELlcTBRHMIDD6AgSInCbvzQ8E=; b=kslIxw0zPD2HNxcHSEDb51vY7LlaSwnou7SjzWBavzxChBbD/cgTwwfwcW5O3I1+Tm KUI7wcYVlv/iy45ZyzjAq23ltYfmIXsBUvMknPHK0DneXQMwW2+O9bb9wllZhY0y3zKM Bmv6qaDHSrv+xIVB/9KE1/0MLiu3v7rgM1g9cNnE1HfRSsWOE1vABCEoPUN/eB7Bi6rK HdqS15RlDLCZuvl+1/IWliXcmRlnhyyz1dnNZIYhhjeOwVv1A4cpQakP45obhwoqrgBE ASitkPXTTyZCc52GYBd4rs25KbFazoK1Q3KhlqQWNc2GyKAZ9vBAX2gPkMeoAxVTUNYV 9McA== 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=ZT1ovF4Qq8SlLHEg4jELlcTBRHMIDD6AgSInCbvzQ8E=; b=ohRAmRzn50YjLgUi/XRb7h2dssvwB3W+ElHncsaky6sICHY+/29TJHrQoNcKNidgom qB2R/bfvzJD7SNPHL3RbvtWJkV9egdeG4JV+NeNv5qvkL5aD+t33ZTxhTQJUp90s1xDq R9in9v9cqaldZ6OgnFxFgbe3Z6/Yp5uPzv/dCyjphvZTV8bZPDn3X7aZYg+GUQSSACTP 7L3SJsvLzoGyfrQhDctnUtiUiIkf3moA/dSLpgDRYNSy9TXieo8VW3OeCW5qB8idph4B lZJUB+xtUf6h54dmh5uSU9Gkc4TGRsE/D8n2bMP1CCktHvxC4pE410PYFyNfvWfxNbOY 2kLg== X-Gm-Message-State: APzg51ABz39jT7sIFvnjYa8T+WnEkpuPzNFAdFCQxbUfW+mj8AC/qv6j KipNYSldyHuktUN+Pm2L5Cma10LflPRUsRIpatkgxQ== X-Google-Smtp-Source: ANB0Vda/9pn5/UCaSPB3MmLRUPmWGJe/kqdzTBnpSbJiGfmvpafaF9CoDmKD9ZuR9TWP2o2GX8YDwxksVrVBQJOKk9k= X-Received: by 2002:a1c:c7c3:: with SMTP id x186-v6mr21583835wmf.109.1537382451003; Wed, 19 Sep 2018 11:40:51 -0700 (PDT) MIME-Version: 1.0 References: <153565372581.3144.14852530580888223510@ietfa.amsl.com> <79C7E169-D962-4328-84DD-C668DD3AA1D1@sn3rd.com> In-Reply-To: From: Warren Kumari Date: Wed, 19 Sep 2018 14:40:14 -0400 Message-ID: To: Christopher Morrow Cc: Sean Turner , sidrops@ietf.org, SIDROps Chairs , sidrops-ads@ietf.org, sidr@ietf.org Content-Type: multipart/alternative; boundary="000000000000e0514b05763dbe14" Archived-At: Subject: Re: [Sidrops] [sidr] I-D Action: draft-ietf-sidr-rtr-keying-16.txt 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: Wed, 19 Sep 2018 18:40:59 -0000 --000000000000e0514b05763dbe14 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 19, 2018 at 2:17 AM Christopher Morrow wrote: > Howdy sidrops folks, this document was left hanging in SIDR, it probably > was better fit to sidr-ops, so let's get Sean to re-spin a re-named > document, auto-adopt that and chat up any changes/etc between now and > 'meeting time' ? > > Ideally we can turn around after the meeting breaks and WGLC this document > in SIDROPS, unless changes are requested (of course!) :) > This sounds like a grand plan! I have"draft-ietf-sidrops-bgpsec-rollover-04 - BGPsec Router Certificate Rollover - RFC Ed Queue : MISSREF for 281 days" sitting in my document queue. It's been awaitin' on draft-ietf-sidr-rtr-keying for almost 10 months, and it's making my twitchy :-) W > > thanks! > -chris > > On Thu, Aug 30, 2018 at 11:30 AM Sean Turner wrote: > >> This version I believes addresses the two outstanding issues Sandy raised >> during her review. >> >> spt >> >> > On Aug 30, 2018, at 14:28, internet-drafts@ietf.org wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Secure Inter-Domain Routing WG of the >> IETF. >> > >> > Title : Router Keying for BGPsec >> > Authors : Randy Bush >> > Sean Turner >> > Keyur Patel >> > Filename : draft-ietf-sidr-rtr-keying-16.txt >> > Pages : 18 >> > Date : 2018-08-30 >> > >> > Abstract: >> > BGPsec-speaking routers are provisioned with private keys in order to >> > sign BGPsec announcements. The corresponding public keys are >> > published in the global Resource Public Key Infrastructure, enabling >> > verification of BGPsec messages. This document describes two methods >> > of generating the public-private key-pairs: router-driven and >> > operator-driven. >> > >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >> > >> > There are also htmlized versions available at: >> > https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-16 >> > https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-16 >> > >> > A diff from the previous version is available at: >> > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-16 >> > >> > >> > Please note that it may take a couple of minutes from the time of >> submission >> > until the htmlized version and diff are available at tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > I-D-Announce mailing list >> > I-D-Announce@ietf.org >> > https://www.ietf.org/mailman/listinfo/i-d-announce >> > Internet-Draft directories: http://www.ietf.org/shadow.html >> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000e0514b05763dbe14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep = 19, 2018 at 2:17 AM Christopher Morrow <morrowc.lists@gmail.com> wrote:
Howdy sidrops folks, thi= s document was left hanging in SIDR, it probably was better fit to sidr-ops= , so let's get Sean to re-spin a re-named document, auto-adopt that and= chat up any changes/etc between now and 'meeting time' ?

<= /div>
Ideally we can turn around after the meeting breaks and WGLC this= document in SIDROPS, unless changes are requested (of course!) :)

This sounds like a grand plan!=C2=A0

I = have"draft-ietf-sidrops-bgpsec-roll= over-04 -=C2=A0BGPsec Router Certificate Rollover - RFC Ed Queue : M= ISSREF for 281 days" sitting in my document queue. It's been await= in' on=C2=A0draft-ietf-sidr-rtr-keying for almost 10 months, and it'= ;s making my twitchy :-)

W


=C2=A0

thanks!
-chris

On Thu, Aug 30, 2018 at 11:30 AM Sean Turner &= lt;sean@sn3rd.com&g= t; wrote:
This v= ersion I believes addresses the two outstanding issues Sandy raised during = her review.

spt

> On Aug 30, 2018, at 14:28, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Secure Inter-Domain Routing WG of the= IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Router Keying for BGPsec
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Randy Bush
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Sean Turner
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Keyur Patel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-sidr-rtr-keying-16.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 18
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2018-08-30
>
> Abstract:
>=C2=A0 =C2=A0BGPsec-speaking routers are provisioned with private keys = in order to
>=C2=A0 =C2=A0sign BGPsec announcements.=C2=A0 The corresponding public = keys are
>=C2=A0 =C2=A0published in the global Resource Public Key Infrastructure= , enabling
>=C2=A0 =C2=A0verification of BGPsec messages.=C2=A0 This document descr= ibes two methods
>=C2=A0 =C2=A0of generating the public-private key-pairs: router-driven = and
>=C2=A0 =C2=A0operator-driven.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/dr= aft-ietf-sidr-rtr-keying/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf= -sidr-rtr-keying-16
> https://datatracker.ietf.org= /doc/html/draft-ietf-sidr-rtr-keying-16
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-sidr-rtr-keying-16
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--000000000000e0514b05763dbe14-- From nobody Wed Sep 19 12:23:08 2018 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 422CD130EAC for ; Wed, 19 Sep 2018 12:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 c-Nb63lZC7Al for ; Wed, 19 Sep 2018 12:23:05 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 E0415130E61 for ; Wed, 19 Sep 2018 12:23:04 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id y20-v6so5861817edq.2 for ; Wed, 19 Sep 2018 12:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W9fEtvHGNEYwctGrtP5yqAS0W8s0KBLl57L4UXm6f4E=; b=aB3es42jJYAB+sGtNDWEid2t8kD0W6IxIiIeHjymuUaojVwqxUzu7tKx/kg7EVJ21i Gezht8XPXR4zjYnZ/kv44yD0bN4wIAxzbg4U3uNn8nkyMkF4TI0QpdfylQJePKyg/MvB mU0/aWomre64FAqv/4TYJ00hf76JxIjBxrukk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W9fEtvHGNEYwctGrtP5yqAS0W8s0KBLl57L4UXm6f4E=; b=k6l+E8SYZP6hhYiBk10Z0DaQ1iJE4umiWHx1Myd8kiVdPAwUCnVCTHroY1wh5tDxg2 e7OOOWSx256lcHTWK/MXWDyAf3PqADK/x7zMPNI6OgmcKsZFhbNeTnuPYBbhJDNe9O0u enUgPOS49SlYuQ+Ra4m3dXLc5/GZQon+ltNTdjQIOLWjmO9oIf1Cw2wp2K9AeXbbylS9 4MBgfUXOcVAZDxR2FDZw5RG65efKIk3p4D2OSsLOqMY7K+vS2QudOdpZwo9n7TqOz0T4 qnQcAWUlRFyCpbBGl6CmSxp3jM0X9S9+FYZvEEy+b/FrytH9UNdEbDP19B5uhpB2fS8+ /bNQ== X-Gm-Message-State: APzg51DVMJCndRp2N/tK2ejPEGE/yAdZ2efHnET6GFwjySMAe2np91ZS wT26AYwOapaJ2NDVULJrh+VoCg== X-Google-Smtp-Source: ANB0VdaobNlNK5JH7MN3WzjfqMbgUQn6B8KtA3KzufSVBEqXG69FILiWIexziAArnm1uXv7A+dp7nA== X-Received: by 2002:a50:b2a6:: with SMTP id p35-v6mr57229963edd.215.1537384983347; Wed, 19 Sep 2018 12:23:03 -0700 (PDT) Received: from [5.5.33.81] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id g22-v6sm1687057edb.93.2018.09.19.12.23.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Sep 2018 12:23:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Wed, 19 Sep 2018 15:22:54 -0400 Cc: Christopher Morrow , sidrops@ietf.org, SIDROps Chairs , sidrops-ads@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8EF14543-09C7-4A08-8DD2-03D55671E36E@sn3rd.com> References: <153565372581.3144.14852530580888223510@ietfa.amsl.com> <79C7E169-D962-4328-84DD-C668DD3AA1D1@sn3rd.com> To: Warren Kumari X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sidrops] [sidr] I-D Action: draft-ietf-sidr-rtr-keying-16.txt 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: Wed, 19 Sep 2018 19:23:07 -0000 > On Sep 19, 2018, at 14:40, Warren Kumari wrote: >=20 >=20 >=20 > On Wed, Sep 19, 2018 at 2:17 AM Christopher Morrow = wrote: > Howdy sidrops folks, this document was left hanging in SIDR, it = probably was better fit to sidr-ops, so let's get Sean to re-spin a = re-named document, auto-adopt that and chat up any changes/etc between = now and 'meeting time' ? >=20 > Ideally we can turn around after the meeting breaks and WGLC this = document in SIDROPS, unless changes are requested (of course!) :) >=20 > This sounds like a grand plan!=20 >=20 > I have"draft-ietf-sidrops-bgpsec-rollover-04 - BGPsec Router = Certificate Rollover - RFC Ed Queue : MISSREF for 281 days" sitting in = my document queue. It's been awaitin' on draft-ietf-sidr-rtr-keying for = almost 10 months, and it's making my twitchy :-) I should be able to get this up by the end of the week. spt= From nobody Thu Sep 20 07:13:31 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAF2130DEB; Thu, 20 Sep 2018 07:13:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153745280514.28676.196305805632597236@ietfa.amsl.com> Date: Thu, 20 Sep 2018 07:13:25 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-03.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 14:13:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : BGPsec Algorithms, Key Formats, and Signature Formats Authors : Sean Turner Oliver Borchert Filename : draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-03.txt Pages : 22 Date : 2018-09-20 Abstract: This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Special-Use Algorithm IDs and correcting the range of unassigned algorithms IDs to fill the complete range. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 24 22:25:26 2018 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D52AD131220; Mon, 24 Sep 2018 22:25:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <153785311881.31266.9050138500778961489@ietfa.amsl.com> Date: Mon, 24 Sep 2018 22:25:18 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-00.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 05:25:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Router Keying for BGPsec Authors : Randy Bush Sean Turner Keyur Patel Filename : draft-ietf-sidrops-rtr-keying-00.txt Pages : 18 Date : 2018-09-21 Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-00 https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 24 22:29:57 2018 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 D014213121F; Mon, 24 Sep 2018 22:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 B6oNgcrXShcv; Mon, 24 Sep 2018 22:29:53 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 65B8E131217; Mon, 24 Sep 2018 22:29:53 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id w11-v6so19521203iob.2; Mon, 24 Sep 2018 22:29:53 -0700 (PDT) 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=c85U8ezfGx/mk/TP7uPDvha0xnae3FkV2NoVXstFf70=; b=pD0CWDms+17STdYU6PmoTInb3nqSVX7PhfEDijM9MapGyxBCNqWJ5KSLm9ZTvNcpzJ xN7fUBSEs1wFzFqYN84eMyrPG6/epRoFfK/1dVK7A2Li4qECp+aG8wBDr9O5FdAiTm+J XXT/25GQM6lAL+IbnRijRRIT7pb4uxKOkr8dBntGBJpyWToY/aqaSd4uB+JO3ZAw05mR wKwzf9yJJLjpTd9+96NeuTZtAh0nLpITnl0S4RQqTCAuyMcfg7rP1CXc72A8jpp4NPBK 2+n8s6i5lrbLgnGWqhde8h5JxxFumBoooy6e9lTGtGiPyHdM0UCAITyFI9dG37aElncg yHRw== 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=c85U8ezfGx/mk/TP7uPDvha0xnae3FkV2NoVXstFf70=; b=H7oPQots1zxv4DrNkqgor5PmGIZgpuoVdKYUWNjZ6wjfrucZ1ko3T68nKhrXDS9jTY GsFZUp2IrudoZk1Ra0CWeWxxIp6XH5rA4WF5n3D1pGIe7HLeNIPRPxIblHp4k8541fV6 B2el+im3qYObQNRHvKUsySwiGMsOmsAK6BvE2flVOjHXfSwki84FiqtC/uPMeE+Ui3pm Y9kBxRibUSJpI49f0KlSOxhqA4mYQyMBMYubjEZyRd6spnti9oLtpU+WpkEyQR3rV3f3 FS8LwDO7lsJlUszOUSmj6ErPF/paA14Qsi8xP+5Nsa0c79Th9rZk7j7auH7amJQf1OdK 6JFQ== X-Gm-Message-State: ABuFfoi+QguQG74+PvEZkc76WQyOvcbhnyq9a/64c1ZASiGG4l0JksaZ 9xYLvtkoJmcH7vYD8j/d+our3q8zE+PImihj6vfQLzMp X-Google-Smtp-Source: ACcGV61MD1PGwa0EiBma+rdbxRCWQERcYeFnrav1rc4pWVTZuXLkkaw5VwzwlylLXV2BgBtpcVUzCaAIieT0kbA7CN0= X-Received: by 2002:a6b:294b:: with SMTP id p72-v6mr1600849iop.17.1537853392309; Mon, 24 Sep 2018 22:29:52 -0700 (PDT) MIME-Version: 1.0 References: <153785311881.31266.9050138500778961489@ietfa.amsl.com> In-Reply-To: <153785311881.31266.9050138500778961489@ietfa.amsl.com> From: Christopher Morrow Date: Tue, 25 Sep 2018 01:29:40 -0400 Message-ID: To: sidrops@ietf.org Cc: sidrops-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000002a52080576ab6508" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-00.txt 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, 25 Sep 2018 05:29:56 -0000 --0000000000002a52080576ab6508 Content-Type: text/plain; charset="UTF-8" howdy sidrops folks, this is the last draft standing from the former SIDR WG, it looked more like a SIDROPS draft so we shifted it over and ... in it's former life it was: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ (version 16) I believe the authors simply requested a name change and submitted that... Should we WGLC this or discuss it some on-list or? :) -chris On Tue, Sep 25, 2018 at 1:25 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the SIDR Operations WG of the IETF. > > Title : Router Keying for BGPsec > Authors : Randy Bush > Sean Turner > Keyur Patel > Filename : draft-ietf-sidrops-rtr-keying-00.txt > Pages : 18 > Date : 2018-09-21 > > Abstract: > BGPsec-speaking routers are provisioned with private keys in order to > sign BGPsec announcements. The corresponding public keys are > published in the global Resource Public Key Infrastructure, enabling > verification of BGPsec messages. This document describes two methods > of generating the public-private key-pairs: router-driven and > operator-driven. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-00 > https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --0000000000002a52080576ab6508 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
howdy sidrops folks, this is the last dra= ft standing from the former SIDR WG, it looked more like a SIDROPS draft so= we shifted it over and ... in it's former life it was:
=C2=A0 =C2= =A0https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ (version = 16)

I believe the authors simply reque= sted a name change and submitted that...
Should we WGLC this or discuss = it some on-list or? :)

-chris

On Tue, Sep 25, 2018 at 1:25 AM <= internet-drafts@ietf.org>= ; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the SIDR Operations WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Router Keying for BGPsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rand= y Bush
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sean Turner
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Keyur Patel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sidrops-rtr-keying-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-09-21

Abstract:
=C2=A0 =C2=A0BGPsec-speaking routers are provisioned with private keys in o= rder to
=C2=A0 =C2=A0sign BGPsec announcements.=C2=A0 The corresponding public keys= are
=C2=A0 =C2=A0published in the global Resource Public Key Infrastructure, en= abling
=C2=A0 =C2=A0verification of BGPsec messages.=C2=A0 This document describes= two methods
=C2=A0 =C2=A0of generating the public-private key-pairs: router-driven and<= br> =C2=A0 =C2=A0operator-driven.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-sidrops-rtr-keying/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-s= idrops-rtr-keying-00
https://datatracker.ietf.org/d= oc/html/draft-ietf-sidrops-rtr-keying-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Sidrops mailing list
Sidrops@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sidrops
--0000000000002a52080576ab6508-- From nobody Tue Sep 25 04:01:59 2018 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 6D8EF13128A for ; Tue, 25 Sep 2018 04:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 CodDvosplIM8 for ; Tue, 25 Sep 2018 04:01:54 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99396131288 for ; Tue, 25 Sep 2018 04:01:54 -0700 (PDT) X-Envelope-To: sidrops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w8PA1dJ7074388 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2018 11:01:40 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: Christopher Morrow Cc: sidrops@ietf.org References: <153785311881.31266.9050138500778961489@ietfa.amsl.com> From: Nick Hilliard Message-ID: <6ec2fd14-75f1-d235-8893-8ce3d4805f08@foobar.org> Date: Tue, 25 Sep 2018 12:01:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.1.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-00.txt 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, 25 Sep 2018 11:01:56 -0000 Christopher Morrow wrote on 25/09/2018 06:29: > I believe the authors simply requested a name change and submitted that... > Should we WGLC this or discuss it some on-list or? Can we add flash cards to the n00b guide? Nick From nobody Tue Sep 25 08:18:11 2018 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 645221312F1 for ; Tue, 25 Sep 2018 08:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XxSPTFTNGmJT for ; Tue, 25 Sep 2018 08:18:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C81141312DB for ; Tue, 25 Sep 2018 08:18:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g4p6E-0008VY-5f; Tue, 25 Sep 2018 15:18:06 +0000 Date: Tue, 25 Sep 2018 08:18:05 -0700 Message-ID: From: Randy Bush To: Christopher Morrow Cc: sidrops@ietf.org In-Reply-To: References: <153785311881.31266.9050138500778961489@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-00.txt 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, 25 Sep 2018 15:18:09 -0000 > it's former life it was: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ (version 16) > > I believe the authors simply requested a name change and submitted that... > Should we WGLC this or discuss it some on-list or? :) it only went through 15 revisions in sidr. surely we need a dozen more :) From nobody Tue Sep 25 10:58:06 2018 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 8E96A12785F; Tue, 25 Sep 2018 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2Iaz9GhOH1hM; Tue, 25 Sep 2018 10:58:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222081277CC; Tue, 25 Sep 2018 10:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11928; q=dns/txt; s=iport; t=1537898281; x=1539107881; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=43JZ68tf944grgkSWV+DFokX3jgFskvGCCJePKWi/6U=; b=Pnrj95Dpz0CRDu1ktdWFm3Guoe+2lXbMQfCZ2iQKCc6TV3X/2wYLAJSx BbyIIcz4U9TbQvyJadyOcQ2VsHc6/uZSjzBXog6l9WDOKkfQAiwxhQyku pWyMkoW+1ceBfiBkIo0Wd2CKZDQ69UufrNd9R5Yh/p4PDssBneAY0XEHP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABgdqpb/4gNJK1YAxoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVGCDmV/KAqDaogVjC2BaIkCiDWFPBSBZgsYAQqEA0YCF4N?= =?us-ascii?q?PITQYAQMBAQIBAQJtHAyFOQIBAwEBIUsLEAIBCD8DAgICHwYLFBECBA4FGYM?= =?us-ascii?q?IAYEdTAMVD6QWgS6EMwc9gkQNglGKeheCAIESJwwTgkyCVkUBAQIBAYEqARI?= =?us-ascii?q?BNgodCYI6MYImAo1qE45WLAkChkGDB4NGgxkXgUVKhAeJFot6bYd7AhEUgSU?= =?us-ascii?q?NEDhkcXAVGiEqAYJBCYsNhT5vi1aBH4EeAQE?= X-IronPort-AV: E=Sophos;i="5.54,303,1534809600"; d="scan'208,217";a="457272411" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2018 17:58:00 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w8PHw0ma025231 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Sep 2018 17:58:01 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 25 Sep 2018 13:57:59 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1395.000; Tue, 25 Sep 2018 13:57:59 -0400 From: "Brian Weis (bew)" To: Christopher Morrow CC: "sidrops@ietf.org" , "sidrops-chairs@ietf.org" Thread-Topic: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-00.txt Thread-Index: AQHUVJA4yRhUkSWGO0+BYn+Nc+6cnqUAu3AAgADRFIA= Date: Tue, 25 Sep 2018 17:57:59 +0000 Message-ID: <63A21AC4-4377-4CA9-BA8E-09B2F3351700@cisco.com> References: <153785311881.31266.9050138500778961489@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.168] Content-Type: multipart/alternative; boundary="_000_63A21AC443774CA9BA8E09B2F3351700ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.141, xch-rtp-001.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-00.txt 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, 25 Sep 2018 17:58:05 -0000 --_000_63A21AC443774CA9BA8E09B2F3351700ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzIG1hdHVyZS4gSG93IGFib3V0IFdHTEMgYW5kIGJlIGRvbmUgd2l0aCBpdD8gRG9u4oCZ dCBmb3JnZXQgdGhhdCA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lk cm9wcy1iZ3BzZWMtcm9sbG92ZXItMDQ+IGhhcyBiZWVuIGFwcHJvdmVkIGZvciBwdWJsaWNhdGlv biBidXQgaXMgd2FpdGluZyBvbiBydHIta2V5aW5nIHRvIHB1Ymxpc2jigKYuDQoNClRoYW5rcywN CkJyaWFuDQoNCk9uIFNlcCAyNCwgMjAxOCwgYXQgMTA6MjkgUE0sIENocmlzdG9waGVyIE1vcnJv dyA8Y2hyaXN0b3BoZXIubW9ycm93QGdtYWlsLmNvbTxtYWlsdG86Y2hyaXN0b3BoZXIubW9ycm93 QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpob3dkeSBzaWRyb3BzIGZvbGtzLCB0aGlzIGlzIHRoZSBs YXN0IGRyYWZ0IHN0YW5kaW5nIGZyb20gdGhlIGZvcm1lciBTSURSIFdHLCBpdCBsb29rZWQgbW9y ZSBsaWtlIGEgU0lEUk9QUyBkcmFmdCBzbyB3ZSBzaGlmdGVkIGl0IG92ZXIgYW5kIC4uLiBpbiBp dCdzIGZvcm1lciBsaWZlIGl0IHdhczoNCiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtc2lkci1ydHIta2V5aW5nLyAodmVyc2lvbiAxNikNCg0KSSBiZWxpZXZl IHRoZSBhdXRob3JzIHNpbXBseSByZXF1ZXN0ZWQgYSBuYW1lIGNoYW5nZSBhbmQgc3VibWl0dGVk IHRoYXQuLi4NClNob3VsZCB3ZSBXR0xDIHRoaXMgb3IgZGlzY3VzcyBpdCBzb21lIG9uLWxpc3Qg b3I/IDopDQoNCi1jaHJpcw0KDQpPbiBUdWUsIFNlcCAyNSwgMjAxOCBhdCAxOjI1IEFNIDxpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdy b3RlOg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBTSURSIE9wZXJhdGlvbnMgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUg ICAgICAgICAgIDogUm91dGVyIEtleWluZyBmb3IgQkdQc2VjDQogICAgICAgIEF1dGhvcnMgICAg ICAgICA6IFJhbmR5IEJ1c2gNCiAgICAgICAgICAgICAgICAgICAgICAgICAgU2VhbiBUdXJuZXIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgS2V5dXIgUGF0ZWwNCiAgICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi1zaWRyb3BzLXJ0ci1rZXlpbmctMDAudHh0DQogICAgICAgIFBh Z2VzICAgICAgICAgICA6IDE4DQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTgtMDktMjEN Cg0KQWJzdHJhY3Q6DQogICBCR1BzZWMtc3BlYWtpbmcgcm91dGVycyBhcmUgcHJvdmlzaW9uZWQg d2l0aCBwcml2YXRlIGtleXMgaW4gb3JkZXIgdG8NCiAgIHNpZ24gQkdQc2VjIGFubm91bmNlbWVu dHMuICBUaGUgY29ycmVzcG9uZGluZyBwdWJsaWMga2V5cyBhcmUNCiAgIHB1Ymxpc2hlZCBpbiB0 aGUgZ2xvYmFsIFJlc291cmNlIFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUsIGVuYWJsaW5nDQog ICB2ZXJpZmljYXRpb24gb2YgQkdQc2VjIG1lc3NhZ2VzLiAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgdHdvIG1ldGhvZHMNCiAgIG9mIGdlbmVyYXRpbmcgdGhlIHB1YmxpYy1wcml2YXRlIGtleS1w YWlyczogcm91dGVyLWRyaXZlbiBhbmQNCiAgIG9wZXJhdG9yLWRyaXZlbi4NCg0KDQoNClRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyb3BzLXJ0ci1rZXlpbmcvDQoN ClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnRyLWtleWluZy0wMA0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnRy LWtleWluZy0wMA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rv b2xzLmlldGYub3JnLz4uDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaWRyb3Bz IG1haWxpbmcgbGlzdA0KU2lkcm9wc0BpZXRmLm9yZzxtYWlsdG86U2lkcm9wc0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcm9wcw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNpZHJvcHMgbWFpbGluZyBs aXN0DQpTaWRyb3BzQGlldGYub3JnPG1haWx0bzpTaWRyb3BzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzDQoNCi0tDQpCcmlhbiBXZWlzDQpT ZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zDQpUZWxlcGhvbmU6ICsxIDQwOCA1MjYgNDc5Ng0K RW1haWw6IGJld0BjaXNjby5jb208bWFpbHRvOmJld0BjaXNjby5jb20+DQoNCg== --_000_63A21AC443774CA9BA8E09B2F3351700ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSXTigJlzIG1hdHVyZS4gSG93IGFi b3V0IFdHTEMgYW5kIGJlIGRvbmUgd2l0aCBpdD8gRG9u4oCZdCBmb3JnZXQgdGhhdCAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lkcm9wcy1iZ3Bz ZWMtcm9sbG92ZXItMDQiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXNpZHJvcHMtYmdwc2VjLXJvbGxvdmVyLTA0PC9hPiZndDsgaGFzIGJlZW4gYXBwcm92 ZWQgZm9yIHB1YmxpY2F0aW9uDQogYnV0IGlzIHdhaXRpbmcgb24gcnRyLWtleWluZyB0byBwdWJs aXNo4oCmLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CcmlhbiZuYnNwOzxiciBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMjQsIDIwMTgsIGF0IDEwOjI5IFBN LCBDaHJpc3RvcGhlciBNb3Jyb3cgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3RvcGhlci5tb3Jy b3dAZ21haWwuY29tIiBjbGFzcz0iIj5jaHJpc3RvcGhlci5tb3Jyb3dAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIg Y2xhc3M9IiI+aG93ZHkgc2lkcm9wcyBmb2xrcywgdGhpcyBpcyB0aGUgbGFzdCBkcmFmdCBzdGFu ZGluZyBmcm9tIHRoZSBmb3JtZXIgU0lEUiBXRywgaXQgbG9va2VkIG1vcmUgbGlrZSBhIFNJRFJP UFMgZHJhZnQgc28gd2Ugc2hpZnRlZCBpdCBvdmVyIGFuZCAuLi4gaW4gaXQncyBmb3JtZXIgbGlm ZSBpdCB3YXM6PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2lkci1ydHIta2V5aW5nLyIgY2xhc3M9 IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyLXJ0ci1r ZXlpbmcvPC9hPiAodmVyc2lvbiAxNik8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGJlbGlldmUgdGhlIGF1dGhvcnMg c2ltcGx5IHJlcXVlc3RlZCBhIG5hbWUgY2hhbmdlIGFuZCBzdWJtaXR0ZWQgdGhhdC4uLjxiciBj bGFzcz0iIj4NClNob3VsZCB3ZSBXR0xDIHRoaXMgb3IgZGlzY3VzcyBpdCBzb21lIG9uLWxpc3Qg b3I/IDopPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4tY2hyaXM8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+T24gVHVlLCBTZXAgMjUsIDIw MTggYXQgMToyNSBBTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyIgY2xhc3M9IiI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxiciBjbGFzcz0iIj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnIgY2xhc3M9IiI+ DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTSURSIE9wZXJhdGlvbnMgV0cgb2Yg dGhlIElFVEYuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6 IFJvdXRlciBLZXlpbmcgZm9yIEJHUHNlYzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogUmFu ZHkgQnVzaDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBT ZWFuIFR1cm5lcjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBLZXl1ciBQYXRlbDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBG aWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtc2lkcm9wcy1y dHIta2V5aW5nLTAwLnR4dDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAxODxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE4LTA5LTIxPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO0JHUHNlYy1z cGVha2luZyByb3V0ZXJzIGFyZSBwcm92aXNpb25lZCB3aXRoIHByaXZhdGUga2V5cyBpbiBvcmRl ciB0bzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtzaWduIEJHUHNlYyBhbm5vdW5jZW1lbnRz LiZuYnNwOyBUaGUgY29ycmVzcG9uZGluZyBwdWJsaWMga2V5cyBhcmU8YnIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7cHVibGlzaGVkIGluIHRoZSBnbG9iYWwgUmVzb3VyY2UgUHVibGljIEtleSBJ bmZyYXN0cnVjdHVyZSwgZW5hYmxpbmc8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dmVyaWZp Y2F0aW9uIG9mIEJHUHNlYyBtZXNzYWdlcy4mbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg dHdvIG1ldGhvZHM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7b2YgZ2VuZXJhdGluZyB0aGUg cHVibGljLXByaXZhdGUga2V5LXBhaXJzOiByb3V0ZXItZHJpdmVuIGFuZDxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDtvcGVyYXRvci1kcml2ZW4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaWRyb3BzLXJ0ci1rZXlpbmcv IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpZHJvcHMtcnRyLWtleWluZy88L2E+PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lv bnMgYXZhaWxhYmxlIGF0OjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpZHJvcHMtcnRyLWtleWluZy0wMCIgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtc2lkcm9wcy1ydHIta2V5aW5nLTAwPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRy b3BzLXJ0ci1rZXlpbmctMDAiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNz PSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zaWRy b3BzLXJ0ci1rZXlpbmctMDA8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCnVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5mdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClNp ZHJvcHMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlNpZHJvcHNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5TaWRyb3BzQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lkcm9wcyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyb3BzPC9hPjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpTaWRyb3BzIG1haWxpbmcgbGlzdDxiciBj bGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpTaWRyb3BzQGlldGYub3JnIiBjbGFzcz0iIj5TaWRy b3BzQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lkcm9wczxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPi0tJm5ic3A7PGJyIGNsYXNzPSIi Pg0KQnJpYW4gV2VpczxiciBjbGFzcz0iIj4NClNlY3VyaXR5LCBDU0csIENpc2NvIFN5c3RlbXM8 YnIgY2xhc3M9IiI+DQpUZWxlcGhvbmU6ICYjNDM7MSA0MDggNTI2IDQ3OTY8YnIgY2xhc3M9IiI+ DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRvOmJld0BjaXNjby5jb20iIGNsYXNzPSIiPmJld0BjaXNj by5jb208L2E+IDwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_63A21AC443774CA9BA8E09B2F3351700ciscocom_-- From nobody Wed Sep 26 14:19:45 2018 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 04D0D1294D7 for ; Wed, 26 Sep 2018 14:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 4qJ_bZPg4JC3 for ; Wed, 26 Sep 2018 14:19:41 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 97AC712F1AB for ; Wed, 26 Sep 2018 14:19:40 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id u12-v6so380677wrr.4 for ; Wed, 26 Sep 2018 14:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KQIxh6bh9kMn95eB6Y60UrTrKKXV9xY4jATZizXD1ZI=; b=PQ7jIGFN7r7jHw1nwt3eXdrUMvwOXKiV6N2iPB1SAE9YQRtxH+hTodwwBtJ7bEYWcS XbfIAjeibvLLtgcT0iBzOU2VhbwGR8kYm6QMsn3Ccqtv6rahsVCaqghVt/1uaDFKo2OY ZNUk2i1BBVysrpJY7sVD9EC1q7R4r/lQBk/XfX6ak5EQabjAPMzQtRf0E48QDoa7zr5H vzDcarul1Be1BzyDdjc+COMgmVCiGxbjekCRrnOXAlYze2ZHiKjvbjM0hipTaarU7BK+ QIrU6Ojl9zcCLDKMpudCQpQh05Wy2CM2C04SMY7beYK3F6O/f1a1SKTu6SO1TMbGzD5d 9mMg== 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=KQIxh6bh9kMn95eB6Y60UrTrKKXV9xY4jATZizXD1ZI=; b=dCK9ms+glI2kXHBieaHUjerP04wU1p+/fBT/1oCMnGAgaCzGIZyar+wAZ+j8OLugrM 9Cg+pdbL/845dYh03U5Z6OyfYrYa6JEAtHfBESo6TelVJRE5O3Ip4sFg7mCHxDUdP+ab ky8TTrgtKA5LjM9qu44e2xgjIuqyltX4gyzN4Tf76Tk4/O3bR7T1Wn+XoR5wW9404hFT qoO845o5U5aVnvv9eI+9u/Yo2wP+/myGOGGQhjEF3tyEKgeXB4EbfEgPQ/gPI4zEv5VW 5JBxux2Hg25+8vQYKwtMVf8Dy18GhHpJ2jBHDkY98/IXxmeoKXznpfcItUHgp5F+wpcQ yZWw== X-Gm-Message-State: ABuFfoiJrkGezaZYzpwt+OxBNdzh63OwpfoU+V2QREgBHqq2q+YX9J0q fuAwouPU0W6z/DIfjSGedhPXP80X+a3XzWAGCsuBwg== X-Google-Smtp-Source: ACcGV63TN9yKUkhuLb+FV/c/Fv96pdcbm7DaKMHpIiYJeZtwbhYJ4ITR0rURbkWf/Z5hxCvEe6RRnCzrNtbxpdR9IV8= X-Received: by 2002:adf:c405:: with SMTP id v5-v6mr6315392wrf.20.1537996778701; Wed, 26 Sep 2018 14:19:38 -0700 (PDT) MIME-Version: 1.0 References: <153785311881.31266.9050138500778961489@ietfa.amsl.com> <63A21AC4-4377-4CA9-BA8E-09B2F3351700@cisco.com> In-Reply-To: <63A21AC4-4377-4CA9-BA8E-09B2F3351700@cisco.com> From: Warren Kumari Date: Wed, 26 Sep 2018 14:18:59 -0700 Message-ID: To: bew=40cisco.com@dmarc.ietf.org Cc: Christopher Morrow , SIDROps Chairs , sidrops@ietf.org Content-Type: multipart/alternative; boundary="000000000000a91bcc0576ccc734" Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-00.txt 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: Wed, 26 Sep 2018 21:19:44 -0000 --000000000000a91bcc0576ccc734 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2018 at 10:58 AM Brian Weis (bew) wrote: > It=E2=80=99s mature. How about WGLC and be done with it? Don=E2=80=99t fo= rget that < > https://tools.ietf.org/html/draft-ietf-sidrops-bgpsec-rollover-04> has > been approved for publication but is waiting on rtr-keying to publish=E2= =80=A6. > Approved and waiting for 288 days at this point... and it's making me twitchy... I just realized that bgpsec-rollover is waiting on draft-ietf-SIDR-rtr-keying (not draft-ietf-sidrops-rtr-keying) - this will require some process wonkery to make sure that the RFC Ed know that this is the new one. I'm mentioning here on the hope that I'll remember / someone will remind me to tell the RFC Ed that this replaces that... :-) W > > Thanks, > Brian > > On Sep 24, 2018, at 10:29 PM, Christopher Morrow < > christopher.morrow@gmail.com> wrote: > > howdy sidrops folks, this is the last draft standing from the former SIDR > WG, it looked more like a SIDROPS draft so we shifted it over and ... in > it's former life it was: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ (version > 16) > > I believe the authors simply requested a name change and submitted that..= . > Should we WGLC this or discuss it some on-list or? :) > > -chris > > On Tue, Sep 25, 2018 at 1:25 AM wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the SIDR Operations WG of the IETF. >> >> Title : Router Keying for BGPsec >> Authors : Randy Bush >> Sean Turner >> Keyur Patel >> Filename : draft-ietf-sidrops-rtr-keying-00.txt >> Pages : 18 >> Date : 2018-09-21 >> >> Abstract: >> BGPsec-speaking routers are provisioned with private keys in order to >> sign BGPsec announcements. The corresponding public keys are >> published in the global Resource Public Key Infrastructure, enabling >> verification of BGPsec messages. This document describes two methods >> of generating the public-private key-pairs: router-driven and >> operator-driven. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-sidrops-rtr-keying-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rtr-keying-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >> > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000a91bcc0576ccc734 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Sep 25, 2018 at 10:58= AM Brian Weis (bew) <bew=3D40cisco.com@dmarc.ietf.org> wrote:
It=E2=80=99s mature. How about WGLC and be done with it? Don=E2=80=99t forg= et that <https://tools.ietf.org/html/draft-ietf-sid= rops-bgpsec-rollover-04> has been approved for publication but is waiting on rtr-keying to publish=E2=80=A6.
<= br>
Approved and waiting for 288 days at this point... and it's ma= king me twitchy...

I just realized that bgpsec-rollover is waiting on= =C2=A0draft-ietf-SIDR-rtr-keying (not=C2=A0draft-ietf-sidrops-rtr-keying) -= this will require some process wonkery to make sure that the RFC Ed know t= hat this is the new one. I'm mentioning here on the hope that I'll = remember / someone will remind me to tell the RFC Ed that this replaces tha= t... :-)

W

=C2=A0

Thanks,
Brian=C2=A0

On Sep 24, 2018, at 10:29 PM, Christopher Morrow <christopher.morrow@gmail.c= om> wrote:

howdy sidrops folks, this is the last draft standing from = the former SIDR WG, it looked more like a SIDROPS draft so we shifted it ov= er and ... in it's former life it was:
=C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-si= dr-rtr-keying/ (version 16)

I believe the authors simply requested a name change and submitted tha= t...
Should we WGLC this or discuss it some on-list or? :)

-chris

On Tue, Sep 25, 2018 at 1:25 AM <internet-drafts@ietf.org> wr= ote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the SIDR Operations WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Router Keying for BGPsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rand= y Bush
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sean Turner
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Keyur Patel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-sidrops-rtr-keying-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-09-21

Abstract:
=C2=A0 =C2=A0BGPsec-speaking routers are provisioned with private keys in o= rder to
=C2=A0 =C2=A0sign BGPsec announcements.=C2=A0 The corresponding public keys= are
=C2=A0 =C2=A0published in the global Resource Public Key Infrastructure, en= abling
=C2=A0 =C2=A0verification of BGPsec messages.=C2=A0 This document describes= two methods
=C2=A0 =C2=A0of generating the public-private key-pairs: router-driven and<= br> =C2=A0 =C2=A0operator-driven.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-sidrops-rtr-keying/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-s= idrops-rtr-keying-00
https://datatracker.ietf.org/d= oc/html/draft-ietf-sidrops-rtr-keying-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--=C2=A0
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com=

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


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--000000000000a91bcc0576ccc734-- From nobody Wed Sep 26 15:10:16 2018 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 6CC20130DD5 for ; Wed, 26 Sep 2018 15:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 QJritDW5txFV for ; Wed, 26 Sep 2018 15:10:12 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 6DDA0130DCE for ; Wed, 26 Sep 2018 15:10:12 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id q19-v6so3297087edr.1 for ; Wed, 26 Sep 2018 15:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uXLWpGp/IX14D/GDemAJf3o+SJisWJZzEowv8U+/Uso=; b=iGnZyd0l5wrs5EagbeQNEw+8Id5e1G5dVbyTYjBqFxrni8xL3tRv4GMr9y9CQj8MQS oO9MZQo5jAs2olMxKDFpBSQRKzVd3OWhtNn9RjvhncCltt6IlXxzO28gTAB4XcZNDJKs hYId2Z7v5B+tHy38gTixQRNn0WXPWPA86d7n4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uXLWpGp/IX14D/GDemAJf3o+SJisWJZzEowv8U+/Uso=; b=Ogitmejd+KpQkCs6e0D0Z4Bd1HPYed0Z5lQvYfHma0FCB+2y2devxqPPt+pCXI0U6z 7ZV5xPYoKhDhp0ff4B81Le8pXwo9DFryBy0VpfZZKyEkXAzUovD9ta+pJB+l7bz29x9n bvNWqyo7l5pnAifmnoVMvDgCQZg5HxrFtiyiPFDh1vEpHKLpWwBd7ImxAq+tacujA28U YxTqOxCAb99XSksuCdOA1YkfLFDZzkLJLaKkbNnsup+fXZfrzv4GiG332XZn7mLAxQxo lAmXKkiGhoM9ECcmFZeR9ynlRMDA5QmWr2sRpgy6lceKjWOEoNtAgBZpstdVZIZhd7rC Tx4A== X-Gm-Message-State: ABuFfoigoex2iaHE6FqzyqH4DWXDKSD5qFZCMimjuCjYulN19n+7CRv6 U7Qi1dCgoDdRdt9xzfedW+1HzzlzQV0= X-Google-Smtp-Source: ACcGV62ZmrEo/EdZDShsPuzwB3pz5/NjCXeUQdoBVqTqIy57A3GPbkF/9y33JnLROmwCWHnZCLJ84w== X-Received: by 2002:a50:8612:: with SMTP id o18-v6mr13433994edo.111.1537999810865; Wed, 26 Sep 2018 15:10:10 -0700 (PDT) Received: from [5.5.33.230] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id z49-v6sm303208edz.79.2018.09.26.15.10.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Sep 2018 15:10:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: <63A21AC4-4377-4CA9-BA8E-09B2F3351700@cisco.com> Date: Thu, 27 Sep 2018 00:10:04 +0200 Cc: "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <189732D2-9670-45C6-81EB-B3AC6C13144C@sn3rd.com> References: <153785311881.31266.9050138500778961489@ietfa.amsl.com> <63A21AC4-4377-4CA9-BA8E-09B2F3351700@cisco.com> To: "sidrops-chairs@ietf.org" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rtr-keying-00.txt 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: Wed, 26 Sep 2018 22:10:14 -0000 > On Sep 25, 2018, at 19:57, Brian Weis (bew) = wrote: >=20 > How about WGLC and be done with it?=20 I=E2=80=99m obviously for this as well, but I am a little biased as = I=E2=80=99m one of the authors. spt= From nobody Wed Sep 26 19:35:17 2018 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 08A66127AC2; Wed, 26 Sep 2018 19:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7GLDyBzVLJY8; Wed, 26 Sep 2018 19:06:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650EA124C04; Wed, 26 Sep 2018 19:06:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7FB18B8101C; Wed, 26 Sep 2018 19:06:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sidrops@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180927020642.7FB18B8101C@rfc-editor.org> Date: Wed, 26 Sep 2018 19:06:42 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 26 Sep 2018 19:35:15 -0700 Subject: [Sidrops] =?utf-8?q?RFC_8481_on_Clarifications_to_BGP_Origin_Val?= =?utf-8?q?idation_Based_on_Resource_Public_Key_Infrastructure_=28RPKI=29?= 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: Thu, 27 Sep 2018 02:06:46 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8481 Title: Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) Author: R. Bush Status: Standards Track Stream: IETF Date: September 2018 Mailbox: randy@psg.com Pages: 5 Characters: 9629 Updates: RFC 6811 I-D Tag: draft-ietf-sidrops-ov-clarify-05.txt URL: https://www.rfc-editor.org/info/rfc8481 DOI: 10.17487/RFC8481 Deployment of BGP origin validation based on Resource Public Key Infrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration. This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration. This document is a product of the SIDR Operations Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC