Validation of RPKI Objects Using a Local Cache
Upcoming SlideShare
Loading in...5
×
 

Validation of RPKI Objects Using a Local Cache

on

  • 603 views

Presentation given by Tim Bruijnzeels at IETF 85 in Atlanta, GA, USA on 8 November 2012

Presentation given by Tim Bruijnzeels at IETF 85 in Atlanta, GA, USA on 8 November 2012

Statistics

Views

Total Views
603
Views on SlideShare
581
Embed Views
22

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 22

http://www.ripe.net 22

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Validation of RPKI Objects Using a Local Cache Validation of RPKI Objects Using a Local Cache Presentation Transcript

    • Validation of RPKI objects using a local cacheThursday, November 8, 12
    • Problems with current • Very tight coupling to rsync – Need to process objects not on manifest – Vulnerable to updates happening during fetch • Prefix validate wants to know all ROAs • Implementations use URI as identifiers for objects – Multiple publication points complicated – Same for alternative fetch mechanisms Tim Bruijnzeels, IETF85 2Thursday, November 8, 12
    • Decoupling object retrieval • Use SIA, AIA and CRLDP only for object discovery • Allows for other retrieval mechanisms – rsync – bittorrent – http with / without deltas – multiple publication points – other.. Tim Bruijnzeels, IETF85 3Thursday, November 8, 12
    • Validation using ‘just objects’ find by: find by: Key Identifier hash TA Cert MFT EE CRL there can be SKI AKI AKI only one... TAL latest? CA1 Cert MFT EE signature ok? SKI AKI all objects? CA2 Cert MFT EE SKI AKI Tim Bruijnzeels, IETF85 4Thursday, November 8, 12
    • Differences from current RFCs • Strict interpretation of current repository standards – Some clarification for CAs might be useful: MUST 1 mft, 1 crl, all objects that need to be known • Manifests authoritative source for walking the tree – Ignores objects that the CA does not put on mft – May be strict if objects are missing, e.g. go with last known good state if available • SIA, AIA and CRLDP only for discovery Tim Bruijnzeels, IETF85 5Thursday, November 8, 12