Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06

Brian Dickson <> Mon, 18 June 2012 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9983421F86E1 for <>; Mon, 18 Jun 2012 09:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ciyC3g5+TPDP for <>; Mon, 18 Jun 2012 09:38:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B878A21F86E0 for <>; Mon, 18 Jun 2012 09:38:39 -0700 (PDT)
Received: by werb13 with SMTP id b13so4451735wer.31 for <>; Mon, 18 Jun 2012 09:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dJhmSrgiHr4+BT6drgT0SUW9/EQwJmKVVsOH+SNwt28=; b=ms0XKJSll/04ifJEb3vBtj6D0/AYpRmzob9gU1qItbY18eB9DOFihjg4t+yTh9tECp R3bn9YjYSdGMoDlOwTv6tMmtjVfTEFzgkN9LQQVy/wyk1NB4wlFW8WqzRhT9qSCT6dfx NHXOKbtqZulqhnYe0PJHdUTdNsOEYw/u4Bts7gvAh18lEVkTb4JAVdu2Lki3db9SC24O 7Nw/taYxKCS5AjNl9mbGV0i6Gs7ulXXZPFVXcwS9UNQLEobwuDBxDsGskk1RDI919DEE nCKSpYqEg7DvxIumcJqMBeHfSXYbiQv1Ypzu81+QgZhcbgZ5Pl4Bxm99AbsACh7TRCGV OuzA==
MIME-Version: 1.0
Received: by with SMTP id r2mr2287471wiz.15.1340037518450; Mon, 18 Jun 2012 09:38:38 -0700 (PDT)
Received: by with HTTP; Mon, 18 Jun 2012 09:38:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 18 Jun 2012 12:38:38 -0400
Message-ID: <>
From: Brian Dickson <>
To: Tim Bruijnzeels <>
Content-Type: multipart/alternative; boundary=f46d044286dc45de7504c2c1cc57
Cc: "Murphy, Sandra" <>, "" <>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Jun 2012 16:38:41 -0000

While I think it is a subtle and "fine print" issue, I think it may be
obvious enough that other folks aren't commenting, which is why there are
not a lot of comments on this.

However, this is one case where silence should not be seen as consent.

One good analogy is the DNSSEC method for determining
consistency/completeness: a DNSSEC signature set is expected to contain a
set of NSEC or NSEC3 records which "prove" the existence or non-existence
of every possible name in a given zone. The records form a "ring" which
must be unbroken and complete.

Even if it isn't part of the wire format, and even if some elements of it
are implementation-dependent, there should be at least recommendations, if
not requirements, that any data retrieved be checked for completeness, so
as to prevent downgrade attacks or vulnerabilities introduced by sloppy



On Mon, Jun 18, 2012 at 7:09 AM, Tim Bruijnzeels <> wrote:

> On 16 Jun 2012, at 22:59, Pradosh Mohapatra wrote:
> > Hi Tim,
> >
> >
> >>> Prefix validate assumes full knowledge of all applicable ROAs (or
> other sources of information if they are used) and I believe this should be
> stated more strongly.
> >>>
> >>> The security considerations section addresses the possibility of a
> malicious attacker tampering with the database that is used for validation.
> It does not address the possibility of a database becoming incomplete for
> other reasons.
> >>
> >> This is the main point I wanted to make. I believe this can be easily
> addressed by just stating the requirement in this document. Perhaps
> something along these lines at the end of the first paragraph in the
> security consideration section:
> >>
> >> "Additional or missing records resulting from retrieval and/or
> validation errors can lead to the same problems."
> >>
> >> The following was just a discussion on how RPs can mitigate these
> problems. But.. perhaps this is better addressed in a separate BCP, or
> future work on specifications related to the repository and
> retrieval/validation by RPs.
> >>
> >> If the WG can agree with this then I can support last call..
> >
> >
> > I do not agree this is a "security" issue. I am guessing you meant
> permanent/eventual inconsistencies between the local and global
> repositories (since transient inconsistencies will always be there). That
> kind of inconsistency is most certainly a (protocol) implementation error
> and has to be dealt with at that layer.
> >
> I see your point about security, I don't really mind which section
> addresses this.
> With inconsistencies I did not mean that the validated cache is out of
> date, which I agree, will always be there even if it could be minimised.
> The inconsistencies I refer to are different in nature. It's that the
> snapshot that the RP tool got when it validated is in itself inconsistent:
> surplus or missing ROAs, or the hash of 1 or more ROAs doesn't match.
> Longer discussion omitted, but at this point the RP just doesn't know for
> certain what to do and guidance is needed. This is where *explicitly*
> stating a strong requirement, rather than leaving it implicit, in
> pfx-validate comes in..
> Having this will help to either come up with best practices for RP tools,
> or preferably improvements to the repository related standards.
> Anyway, I get the feeling that I am the only one here who sees this as a
> problem, so I guess the rough consensus is there..
> Tim
> _______________________________________________
> sidr mailing list