Subject: Re: [Sidr] Multiple Signatures on a ROA: Proposal

From: Matt Lepinski <[email-masked]>
Date: Sat, 01 Mar 2008 13:46:55 -0500

Rob,

Thanks for your feedback.

I understand your skeptism about the need for multiple signatures. 
Ultimately, no one can see the future well enough to know how often such 
a mechanism will be needed. However, if the mechanism is needed and we 
don't support it, it's not the kind of thing that can be added later in 
any reasonable manner.

With regards to your comments, I'm happy to clearly specify that (1) All 
signatures must be valid or the ROA; and (2) Two signatures covering 
overlapping IP address ranges are not allowed.

With regards to the ExactMatch flag, the intent of the ExactMatch flag 
is to specify the rules for matching the prefix(es) in a ROA with the 
prefix(es) advertised in a BGP UPDATE. That is, when ExactMatch is TRUE 
the AS must advertise exactly the prefix(es) listed in the ROA, where as 
if ExactMatch is FALSE then the AS may advertise more specific (longer) 
prefixes than those listed in the ROA. In either case, I belive the 
addresses in the ROA should exactly match the (union) of the addresses 
in the EE certificate(s) regardless of whether there is one or more 
signature on the ROA.

Personally, I would like to see the specification dictate that any 
SignerInfo whose digest algorithm is not SHA-256 be ignored (treated as 
if it were not present) by the validation algorithm. I do not believe 
this adds much additional complexity and I believe that if we do not 
such a provision, then we will be stuck with SHA-256 forever (and if we 
do add such a provision then at some point in the distant future the 
spec could be updated to allow backwards-compatible migration to a new 
digest algorithm).

That point aside for the moment, based on your comments I would propose 
to re-write the ROA validation algorithm as follows.
[Please let me know if you have any suggestions for improving this text, 
especially if you see a way to make the description simpler/clearer]

1. Verify that the ROA syntax complies with the syntax specified in 
draft-ietf-sidr-roa-format. If the syntax is improper in any way, then 
the ROA is invalid.

2. Process each SignerInfo object in the SignerInfos list, as follows:

   2.1 Obtain an EE certificate whose Subject Key Identifier
        (SKI) matches the sid field of the SignerInfo object.
        This certificate may be obtained from the certificates field
        of the SignedData object (if present), the resource PKI
        repository system, or a local cache.

   2.2 Use the public key in the EE certificate to verify the
          signature on the ROA. If the signature is invalid then
          the ROA is invalid.

   2.3 Verify that the EE certificate is a valid end-entity
          certificate in the resource PKI by constructing a valid
          certificate path to a trust anchor. (See
          draft-ietf-sidr-res-certs for more details.)
          If the EE certificate is invalid then the ROA is invalid.

   2.4 Verify that the EE certificate has an IP Address Delegation
          extension [RFC3779]. If the IP address range specificed in
          the RFC 3779 extension overlaps with any IP address
          range corresponding to a previous SignerInfo Object,
          then the ROA is invalid.

   3. Compute the union of IP address ranges in the RFC 3779
       extensions of the EE certificates used to verify the signatures
       in Step 2. If this union exactly matches the IP address
       prefix(es) in the ROA, then the ROA is valid, otherwise it is
       invalid.

Note: Again, I would propose adding a Step 2.0 that says "If the 
digestAlgorithm of the SignerInfo object is not SHA-256, then ignore the 
SignerInfo object and proceed to the next SignerInfo object."

- Matt Lepinski :->

Rob Austein wrote:

>I remain quite skeptical about the need for this, but will suspend
>disbelief on that point for the remainder of this message.
>
>The proposal is too complicated for the stated purpose, mostly because
>it allows overlapping resource sets.  That drags in all sorts of fun
>topics, such as partial overlaps, overlaps with multiple algorithms,
>downgrade attacks, deciding how many good signatures is enough,
>etcetera ad nauseum.
>
>Complicated decision trees means multiple code paths.  Rarely used
>code paths will be buggy.  Buggy code paths will be an attack vector.
>This is supposed to be security software.  Keep it simple.
>
>If you must support multiple signatures, do it as simply as possible:
>
>- All signatures must be good, if any are bad, so is the ROA.  Full
>  stop.
>
>- Overlaps are not allowed, full stop.
>
>- If the ROA's exactMatch field is true, the prefixes listed in the
>  ROA must be an exact match for the union of the set of prefixes
>  covered by the certs; otherwise, the prefixes listed in the ROA must
>  be a subset (possibly improper) of the union of the resources in the
>  cert.
>_______________________________________________
>Sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr
>
>  
>

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

---

From: Danny McPherson <[email-masked]>
Date: Mon, 17 Mar 2008 20:52:24 -0600

On Jan 17, 2008, at 7:53 AM, Matt Lepinski wrote:

> At IETF 70, Geoff and I agreed to put together a concrete proposal  
> for how multiple signatures on a ROA would work.

Matt et al.,
Upon thinking about this more, I'm now wondering why
this would be needed beyond one example.  That example
is where multiple CAs 'own' the prefixes that are being
aggregated and therefore a single CA certificate for the
aggregate cannot be obtained.

Does anyone have other examples of where this would
arise?

I still stand by by statement that SIDR should NOT
impose any constraints that do not exist in the routing
system, but I'm wondering how likely the probability of
the above is, or if there are other cases where this
may occur.

-danny

---

From: Geoff Huston <[email-masked]>
Date: Tue, 18 Mar 2008 14:07:12 +1100

> Does anyone have other examples of where this would

Here's a hypothetical example: An academic and research network with academic instituations as members is the exclusive upstream provider for these institutions.  The member institutions are all holders of legacy space, and the a & r network would like to do the right thing bgp-routing aggregation-wise and announce the maximallu spanning aggregation across all these elements. But even when there are adjacent address blocks the signatories are distinct entities, and the A & R network would need to get the ROA for the aggregate signed by both (or as many as could be aggregated into a single advertisement) in order to generate a ROA for the aggregate.
 
> the above is, or if there are other cases where this

Someone would need to troll through the BGP table dumps to find out how often this occurs in practice.

  Geoff

---

From: Geoff Huston <[email-masked]>
Date: Tue, 18 Mar 2008 15:21:11 +1100

Thanks to Russ Mundy for these minutes.

   Geoff & Sandy

SIDR - IETF 71
Securing Inter-Domain Routing (SIDR) WG Meeting

10 Mar 2008, 1740 - 1950

CHAIRS:
  Geoff Huston &; Sandy Murphy

NOTE TAKER:
  Russ Mundy

AGENDA:

  1. Administrivia
      Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html
      Blue Sheets
      Agenda Bashing

  2. SIDR and Origin Validation - Geoff Huston

  3. Certificate Policy and CPS drafts -  Steve Kent
        Certificate Policy
          http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-03.txt
        CPS for ISPs
          http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-isp-02.txt
        CPS for Registries
          http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-03.txt

  4. RPKI Architecture Update - Matt Lepinski
        http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-03.txt

  5. Route Originations - Matt Lepinski
        http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-02.txt

  6. Repository Structure  - George Michaelson
        http://www.ietf.org/internet-drafts/draft-huston-sidr-repos-struct-01.txt

  7. ROA Validation  -  George Michaelson
        http://www.ietf.org/internet-drafts/draft-huston-sidr-roa-validation-00.txt

  8. Bogon Origin Attestations - Geoff Huston
        http://www.ietf.org/internet-drafts/draft-huston-sidr-bogons-00.txt

SUMMARY:

  The WG agenda items covered the overall approach being used by the
  WG to address the issues of origin validation and then examined a
  number of specific aspects of routing origination attestations in
  relation to a Resource PKI.

  Following a report to the WG from RPSEC on requirements for BGP
  routing security, it was noted that no clear guidance on the topic
  of AS Path validation was forthcoming. SIDR should undertake a
  solution for AS Path validation. The AD suggested that the charter
  revision should be done by IETF72.

  One general comment at the end of the meeting was that it would be
  useful to have a roadmap for the relationship and anticipated timing
  of completion of the various work items discussed during the
  meeting.  The co-chairs acknowledged that this might be useful, but
  should be discussed further on the WG mailing list.

NOTES:

  SIDR and Origin Validation

    Geoff Huston presented a status report on the SIDR Working Group
    activities relating to origination validation in inter-domain
    routing.

    The presentation provided a summary of the reason for creation of
    SIDR and set of requirements for the working group.  The main
    focus of the working group is the specification of a PKI that
    supports validation of origination information contained in the
    routing system, and the manner in which validation tools could be
    incorporated into the routing architecture.
  
    Questions / Comments:

    There was no controversy related to the presentation but the AD
    asked where the information was described.  Geoff acknowledged
    that he needed to write an RFC to document much of what he
    presented in his summary.

    During the presentation, there was also a discussion about the
    SIDR requirements and work being "locked to RPSEC".  The general
    sense of the room was that this should be changed in the SIDR
    charter - no one in the room objected to this change.  Part of
    this discussion of SIDR working group scope was taking on solving
    the problem of path validation.  The sense of the room was that
    SIDR should undertake a solution for path validation.  The AD
    suggested that the charter revision should be done by IETF 72.

    ACTIONS:

    - Chairs to propose a revised charter for the SIDR WG to address
      the topic of measures to support validation of the AS Path.

    - Draft to be proposed to the WG on the overall approach to
      Origination validation. Geoff Huston will work on this draft.

  Certificate Policy and CPS drafts

    Steve Kent presented on three CP and CPS drafts. The most
    significant changes since the previous WG meeting has been with
    the CPS template for RIRs.  The majority of this work focused on
    enhancing the template so that less work will be needed on the
    part of RIRs using the templates.  Steve has worked with APNIC in
    completing their CPS, which they were able to do in two days.  One
    important aspect pointed during the presentation was that a
    business PKI that is separate from the resource PKI will be
    required.

    Questions / Comments:

    During the discussion from the floor, there was a suggestion that
    a complete template be created that could be used by ISPs. This
    was accepted as a good suggestion.

    Another comment was that it would be useful to have a template that
    says the ISP has no liability of any sort.

  RPKI Architecture Update
  
     Matt Lepinski presented on the RPKI architecture. The opening
     request is for everyone to read and comment on the draft.  Matt
     considers the current text is to be inadequate in certain areas,
     and requests inputs with specific, new text.

    Questions / Comments:

    There was some discussion about changing the scope of this
    document so that it would align with the expected charter changes.
    The general sense of the room was to keep the current scope and
    focus on completing the document. The document probably needs some
    clarification regarding intended scope. Additionally, the document
    is intended to provide examples rather than explicit directions so
    some words need to be updated.

    ACTIONS:

    - Draft to be revised to clarify intended scope
      regarding the architecture of the RPKI and reference related
      documents concerning further details of the use of Manifests,
      ROAs, BOAs and the forms of potential use in supporting routing
      activities.
    
  Route Originations
     	
    Matt Lepinski presented on the current ROA specification document
    and the current issue relating to whether to add the capability for
    multiple signatures into a ROA or not. A specification as to how
    multiple signatures could be included in the ROA was presented.

    Questions / Comments:

    There was a significant discussion about the ROA format and number
    of signatures on a ROA. There were generally two (opposing) views
    expressed there were largely the same as have been expressed on
    the mail list. The minute takers' general summary of the issue is:

      Supporters of multiple signatures: SIDR work should not
      constrain or restrict the way in which the routing system and
      resource assignments operate currently or in the future.

      Opponents of multiple signatures: This is an effort to solve a
      problem that is extremely small (or non-existent) which
      introduces significant complexity of the validation
      implementations (and possibly all validations).
 
    During the discussions, some new ideas such as specifying the use
    of multiple signatures on a ROA but defining that only one
    signature will be used initially on a ROA - a request was made for
    Jeffrey Hass write up this idea for the WG.

    There was also a suggestion that if multiple signatures were used,
    they should only be applied when multiple parties were involved.

    Geoff suggested that it might be useful to specify that validation
    of a ROA would not be done over any larger address space than
    contained in the ROA. A ROA cannot be used to validate any object
    that is larger than the span of the address in the ROA. The
    implication of this limitation is that if it is required to sign an
    aggregate address object where the components are drawn from
    distinct validation paths, then multiple signatures in the ROA would
    be necessary.
 
    ACTIONS:

    - Jeffrey Hass to describe an approach to multiple signatures on a
      ROA where the case of multiple signatures is defined, but note
      intended use to be constrained to single signatures.

    - Multiple signatures in a ROA to be taken to the WG mailing list.
   
  Repository Structure
  
    George Michaelson next presented on the Repository Structure
    draft. The draft has been pretty much rewritten since the -00
    draft, in response to a batch of inputs.  The slides provide a
    summary of the changes from the 00 version.
  
    The authors believe that the 01 version incorporates the comments
    they received to date.  They would also like to have further
    review and comments on the draft.
      
    Questions / Comments: 

    During this presentation, a member of the
    working group asked if this was the right time to discuss the
    issues around the use of rsync as defined in the specification.
    There have been discussions about this on the WG list but they
    have not been conclusive.  After some discussion in the meeting,
    Sandy took an action to write a description and summary of the
    rsync related issues and send it to the WG list and AD.  At this
    point, it sounds like the working group members in the room see
    the need to have specific agenda time to discuss these issues at
    the IETF72 SIDR WG meeting.

    ACTIONS:

    - Sandy Murphy to write a description of the issues in the use of
      RSYNC in the RPKI specification, and circulate this to the AD
      and the WG.

  ROA Validation

    George Michaelson presented on ROA Validation.  The list of issues
    in the last slide of the presentation may not be complete but are
    likely the ones that need to be worked on first - comments are
    solicited.

    Questions / Comments:

    Some of the substantive comments that were raised from WG members
    in the room related to operational timeliness and the amount of
    time needed to effect changes to signed originations, e.g., an ISP
    moves all traffic from one link to another (changing origination
    point and issuing a new ROA) but their traffic is not being
    delivered everywhere since some places are validating on the old
    ROA - a 24 hour cycle to get the new information in place is not
    operationally acceptable.  Geoff & Steve both pointed out that
    relying parties can update information more frequently than 24
    hours but there is no way to force people to update information on
    any particular period of time. The generic response to this was to
    pre-provision the necessary security credentials in the RPKI in
    advance of the use of a particular origination arrangement in the
    routing system.

    There was also discussion about approaches that were needed during
    the transition period of particular adoption, when ROAs are being
    issued for some but not all originations. Some ideas are included
    in the draft and summarized in the slides. The working group was
    asked to think about transition and contribute additional ideas.

  Bogon Origin Attestations

    Geoff Huston presented on Bogon Origin Attestations. The concept
    motivating the BOA idea is to provide a mechanism for legitimate
    holders of resources to make an authenticatable statement the
    certain resources should not be appearing in the routing system.
    In general, BOAs are modelled after ROAs but if a relying party
    encounters both a ROA and a BOA for a given space, the ROA will
    always override a BOA.