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

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 1 Jun 2012 23:00:13 +0000

The authors have stated that they believe that draft-ietf-sidr-pfx-validate-06 "BGP Prefix Origin Validation" is ready for a working group last call.

The draft can be accessed at http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-06 and https://datatracker.ietf.org/doc/draft-ietf-sidr-pfx-validate/

This announces the beginning of the wglc.  The last call will end on Friday, 15 Jun 2012.

Please judge whether you believe that this work is ready for publication and send any comments to the list.

--Sandy, speaking as wg co-chair

---

From: Warren Kumari <[email-masked]>
Date: Sat, 9 Jun 2012 18:01:25 -0400

> Please judge whether you believe that this work is ready for publication and send any comments to the list.

I'd like to note that there was IPR filed on this (submitted on 2011-06-02, posted at https://datatracker.ietf.org/ipr/1569/. The title
of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-sidr-pfx-validate-01."")).

I do not recall there being any real discussions as to how the WG felt about advancing an encumbered draft (but perhaps there was when it was adopted (the pre-WG doc was also encumbered)?), but figured I should mention.

I have read and support this draft (although, in case it wasn't obvious, would prefer it if it had no IPR…)

W

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
> 

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett

---

From: Ed Kern <[email-masked]>
Date: Mon, 11 Jun 2012 14:05:00 -0700

Have read numerous versions along the way....Am happy and support 06 for advancement.

Ed

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 12 Jun 2012 10:31:19 +0200

Hi,

> The authors have stated that they believe that draft-ietf-sidr-pfx-validate-06 "BGP Prefix Origin Validation" is ready for a working group last call.

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. 

In particular I am worried about repositories:
1- being completely unreachable for a prolonged time
2- being inconsistent

@1:

A relying party tool may choose to use old information if a repository can not be reached. This assumes that the RP has this old data, and it will only work for a while. There is some unclarity what to do if the manifest goes stale (next update time in the past) vs a manifest EE certificate expiring (http://tools.ietf.org/html/rfc6486#section-5.1 dictates a one-time use EE cert should match this).

In particular consider this case:

Parent CA:
- has cert for 10/8
- ROA for 10.0/16 AS A
- signed cert to child for 10.0.0.0/22

Child CA:
- publication point is unreachable, old data expired (new RP instances unaware even)

There is a very real possibility that the parent's ROA invalidates the child announcements.

I believe that the only reasonable, automated, action an RP can take in this case is to disregard any INRs mentioned on the child CA's cert whose pub point is unreachable.

@2:

With inconsistent I mean the following cases:
- hash invalid for ROA
- missing ROA
- surplus ROA

The RP has a very tough time deciding what to do:
- the invalid ROA could be a publication error, or it could be that another ROA with the same name was intended to be published, but we didn't see it
- a missing ROA could validate an announcement that is now considered invalid because of another ROA
- the surplus ROA's intention is unclear, it could be that the CA forgot to delete and revoke this, and it's invalidating announcement(s)

I understand that the authors intended manifests as a replay detection mechanism and most of the wording regarding validation uses SHOULDs and 'local policy'. However, I believe that this is not strong enough for pfx-validate. Local policy sounds very reasonable when in doubt, but I have no faith that operators will have enough knowledge to make educated decisions in all these cases. By and large I expect that operators will go with the *default* local policy decisions that are implemented in the RP tool they use.

In short I think that pfx-validate's requirement for full knowledge dictate that there MUST be a valid manifest listing the ROAs the CA intended to publish, they MUST all be present, all be valid, and no additional ROAs for the publication point can be considered.

---

From: Keyur Patel <[email-masked]>
Date: Tue, 12 Jun 2012 02:23:16 -0700

+1.

Regards,
Keyur

On 6/11/12 2:05 PM, "Ed Kern" <[email-masked]> wrote:

>> The authors have stated that they believe that
>> draft-ietf-sidr-pfx-validate-06 "BGP Prefix Origin Validation" is ready for a
>> working group last call.
>> 
>> The draft can be accessed at
>> http://tools.ietf.org/html/draft-ietf-sidr-pfx-validate-06 and
>> https://datatracker.ietf.org/doc/draft-ietf-sidr-pfx-validate/
>>

---

From: "George, Wes" <[email-masked]>
Date: Tue, 12 Jun 2012 08:22:47 -0400

I have read this draft and previous versions and I support publishing it.

One nit - we've had several conversations about whether to use AS_Path as synonymous with AS4_Path since we require (with a MUST) support for 4-octet ASNs. I don't remember which way we came down on the matter, whether to explicitly say AS4_PATH since that is what will really be used, or to leave that as an exercise for the implementer.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murphy, Sandra
> Sent: Friday, June 01, 2012 7:00 PM
> To: [email-masked]
> Subject: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06
>
> The authors have stated that they believe that draft-ietf-sidr-pfx-
> validate-06 "BGP Prefix Origin Validation" is ready for a working group
> last call.
>
> The draft can be accessed at http://tools.ietf.org/html/draft-ietf-sidr-
> pfx-validate-06 and https://datatracker.ietf.org/doc/draft-ietf-sidr-
> pfx-validate/
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 12 Jun 2012 15:50:45 +0200

> One nit - we've had several conversations about whether to use AS_Path as synonymous with AS4_Path since we require (with a MUST) support for 4-octet ASNs. I don't remember which way we came down o…

… i'd leave it that excercise to the implementer.
for internal APIs (ala "give me the rightmost AS") usually you operate on a normalized
representation of data and not the binary message stream.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 12 Jun 2012 16:48:09 +0000

Speaking as regular ol' member:

wrt:

>One nit - we've had several conversations about whether to use 
>AS_Path as synonymous with AS4_Path since we require (with a 
>MUST) support for 4-octet ASNs. I don't remember which way 
>we came down on the matter, whether to explicitly say 
>AS4_PATH since that is what will really be used, or to leave 
>that as an exercise for the implementer.

I do not believe that AS4_PATH would "really be used" by a bgpsec capable router.

The MUST support for 4 byte AS numbers means that the following text from RFC4893 applies:

   The new attributes, AS4_PATH and AS4_AGGREGATOR SHOULD NOT be carried
   in the UPDATE messages between NEW BGP peers.  A NEW BGP speaker that
   receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE
   message from a NEW BGP speaker SHOULD discard these path attributes
   and continue processing the UPDATE message.

Each neighbor that has negotiated the bgpsec capability  is a "NEW BGP speaker" because it must support 4 byte ASNs.  NEW BGP speakers use 4 byte ASNs in the AS_PATH (not AS4_PATH).

The RFC4893 text says SHOULD rather than MUST, so it is possible that a bgpsec speaker might actually receive the AS4_PATH attribute, but dropping the attribute is expected and just fine.

--Sandy, speaking as regular ol' wg member

________________________________________
From: George, Wes [[email-masked]]
Sent: Tuesday, June 12, 2012 8:22 AM
To: Murphy, Sandra; [email-masked]
Subject: RE: WGLC for draft-ietf-sidr-pfx-validate-06

Thanks,

Wes George

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 15 Jun 2012 14:42:10 -0400

True in the context of bgpsec. But this is just pfx-validate. Nonetheless, I am OK with leaving it as an exercise for the implementor -- as Hannes notes, this is how it ends up working anyway.

--John

---

From: Tim Bruijnzeels <[email-masked]>
Date: Sat, 16 Jun 2012 10:43:21 +0200

Hi,

Please allow me to clarify my earlier comments.

> 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 beco…

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..

---

From: Pradosh Mohapatra <[email-masked]>
Date: Sat, 16 Jun 2012 13:59:41 -0700

Hi Tim,

> 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.

- Pradosh

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 18 Jun 2012 13:09:43 +0200

> 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…

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

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Jun 2012 12:38:38 -0400

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
implementations.

IMHO.

Brian

On Mon, Jun 18, 2012 at 7:09 AM, Tim Bruijnzeels <[email-masked]> wrote:

> >>> 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.
> >>
> > 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.
> >
>
> 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

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 26 Jun 2012 21:00:57 +0000

Speaking as regular ol' member

wrt:

>True in the context of bgpsec. But this is just pfx-validate. 

Whoops.  Absolutely right, my bad.  Please disregard my comments.

--Sandy, speaking as regular ol' member
________________________________________
From: John G. Scudder [[email-masked]]
Sent: Friday, June 15, 2012 2:42 PM
To: Murphy, Sandra
Cc: George, Wes; [email-masked]
Subject: Re: [sidr] WGLC for draft-ietf-sidr-pfx-validate-06

--John

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2012 03:51:09 -1000

> 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 RO…

would you like us to pull in the crucial paragraph from sec 6 of
origin-ops?

   Like the DNS, the global RPKI presents only a loosely consistent
   view, depending on timing, updating, fetching, etc.  Thus, one cache
   or router may have different data about a particular prefix than
   another cache or router.  There is no 'fix' for this, it is the
   nature of distributed data with distributed caches.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 29 Jun 2012 18:03:34 +0200

Hi,

>   nature of distributed data with distributed caches.

No, not exactly. I think it makes more sense to have this kind of guidance in an ops targeted document. Here I would just like to see it documented that the same kind of concerns raised with someone able to mess with the validated cache database (adding/removing records) apply to attacks or operational problems that happen before stuff goes into that database.

Addressing this to the best of our abilities in operations and relevant standards is another discussion. One that I would like to save for another thread, and which does not have to block pfx-validate as far as I am concerned.

Tim

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2012 09:36:44 -1000

> other sources of information if they are used) 

no, it can not.  there is no notion of global completeness in the RPKI,
only manifests to resist object removal attack.  from origin-ops

6.  Notes

   Operators should beware that RPKI caches are loosely synchronized,
   even within a single AS.  Thus, changes to the validity state of
   prefixes could be different within an operator's network.  In
   addition, there is no guaranteed interval from when an RPKI cache is
   updated to when that new information may be pushed or pulled into a
   set of routers via this protocol.  This may result in sudden shifts
   of traffic in the operator's network, until all of the routers in the
   AS have reached equilibrium with the validity state of prefixes
   reflected in all of the RPKI caches.

randy