Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT)

Alvaro Retana <> Fri, 30 August 2019 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B3C21209EB; Fri, 30 Aug 2019 12:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cIeSiqfRLOYk; Fri, 30 Aug 2019 12:41:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FEFB1209C9; Fri, 30 Aug 2019 12:41:32 -0700 (PDT)
Received: by with SMTP id r12so9234891edo.5; Fri, 30 Aug 2019 12:41:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=wamo5NCScZ6Dqt+qjUJ3UP1WolaYx7oxBy9eOX820VY=; b=K3YmG513cJ1/vIFUZgfYThfwgYtmmftqB7qv4kyRyjh0Gp0RTsPnnfa5BBIirw/G6j aEGO7rlG+xPqkrJRBibGZtecS1LE992m7QafsQ4oZ7Rqk7ETSATEDNN1mkE4rAnQUd8Y fejfgb5lYh+wSjiWaxwMF/eOAn6k5ZzgjseumuMJda61rvSaKmtejg/fFi5kk3CtONPG EWPLrn+JphEHZ1bMHtK3Z5O8Itn1PJPG8tvy/aO0moi4cxtFYmZfFgnRwxl982v97A8R cNtHhNLe+IDdxrGvbCE3vE+wS3ZvRUuYH054lifon2CWqlLEXvIQNOQ0anNzVbeUa35S 320w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=wamo5NCScZ6Dqt+qjUJ3UP1WolaYx7oxBy9eOX820VY=; b=K2QlIrUOYxKPmefzUX3sZzAoMrwnx0BETVmy59SduGewiyptN4Cq5UrNLydGtdbPC1 hao63sEDKUaAWsEnw3jSDCzq6TBQq69ib/RW275/IXHVoMPzFzYZhDRqL+MxsVJaf9YZ 4fOvOWg1SL7M9R6sJ2ExKlMp5fAlZwqf58XEJ5YEjejkUpIZSabcT8TBuIxHn3VTkooK OJVM31ZSsX+VHlm7rR3gf7VODkCvdcLW2a0BWbdkaynW/GOqYWJ16y/b853t9GTq1Jac 91jMYU6mm/kCGRAlHbbnVpYDF3ABCpCqGGLyaU/l8/okXWCkv3FLBBJycFtwjswWIeHk +FUQ==
X-Gm-Message-State: APjAAAWsEARcy9XPdmK5MRNB28Dz32JEc/ZKQ5Huf3kucf1GIw1P8Dkw aYvn8vxxz7DGE0v972ZvoPXGYwuOe6QZhcbMPo4=
X-Google-Smtp-Source: APXvYqyVndGbcMDflUX8Xlz2aJFq6QQxmyeqv/mups0mDS//ROUhvEsrKyVdwztKEIS3P1tHx/0EPKbhBKxH/OMcxRU=
X-Received: by 2002:aa7:c655:: with SMTP id z21mr17467139edr.87.1567194090589; Fri, 30 Aug 2019 12:41:30 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 30 Aug 2019 15:41:29 -0400
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Date: Fri, 30 Aug 2019 15:41:29 -0400
Message-ID: <>
To: "Sriram, Kotikalapudi (Fed)" <>, The IESG <>
Cc: Warren Kumari <>, Sandra Murphy <>, "" <>, "Murphy, Sandra" <>, Jen Linkova <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000001051a305915acf01"
Archived-At: <>
Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Aug 2019 19:41:35 -0000

Thanks Sriram!

I’m clearing my DISCUSS.


On August 30, 2019 at 1:28:22 PM, Sriram, Kotikalapudi (Fed) ( wrote:


A new version -04 has been uploaded that includes changes
based on your Discuss and other comments.
It took sometime because we (authors) thought it was best to
incorporate all of the IESG reviewers' comments before uploading
a new version. That is done now.

>Given that Algorithm B is more flexible, and that the limitations from
Algorithm A are overcome (§3.4), I would like to see B be the
>I am ok if Algorithm A is mentioned as an alternative (not a
recommendation); one that is less flexible and has specific limitations —
even if those limitations are not expected/assumed, the vulnerability to a
change in conditions should be clearly spelled out.

These main changes per your recommendation are incorporated.
Please take a look at the revised Section 3.7, where we've added
a new Section 3.7.1 to speak about applicability and limitations of
Algorithm A.
You may take a look at the diff:

>Yes…but it is important to clearly mention the known vulnerabilities of
the solutions being proposed.

We have carefully revised the Security Considerations section.
There we mention again the limitations of Algorithm A
and refer back to Section 3.7.1 for details.
We also discuss (in the Security Considerations) the risks
of augmenting the RPF list based on ROA data (per your suggestion).
We also mention the need for "security hardening of
routers and other supporting systems (e.g., Resource PKI (RPKI) and
ROA management systems) against compromise..."

Please let us know if you have any additional comments.
Thanks very much for your help.