Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
On Jul 8, 2015, at 1:30 PM, Sandra Murphy mailto:sa...@tislabs.com>> wrote: I think it would be interesting to hear from the RIR's as to whether they require resources to be unused, and for how long, before a transfer is possible. The reality is that we rarely get transfers of RPKI certified space, but to answer your question: we don’t deny or delay a transfer just because it is RPKI live. -andy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] [Idr] Route Leaks and solutions
(Cc'ing sidr list also since there is interest there too in this topic.) >> If A's customer C does not want A to propagate, then C has a choice not to >> send >> the prefix-route to A in the first place. >> Given that choice, why would C instead choose to poison or downgrade by >> altering RLP bits? >Q: why do people poison routes by jamming in to the aspath ASN which >they want to ignore their prefix/announcement? >A: because knob. Section 5.1 in the route leaks solution draft already discusses possible abuse of the knob (without security / bgpsec). Randy and I were trying to come up with more examples (besides what is in Sec. 5.1). I will include Randy's additional example (that we have discussed here) also in Section 5.1. But, IMHO, so far none of these abuses seems egregious. So the benefit seems to outweigh the 'new attack vector' disadvantage. Explained further below. Even with ROA origin validation, there is the fake-origin-AS attack vector (without bgpsec), but we recognize that ROA origin validation stops all accidental mis-originations. So it is worth it. The determined attacker may still use fake-origin-AS attack; but that would be mitigated by bgpsec (when it is deployed). Likewise, the evolution path for route leaks solution could be as follows: Current BGP (without route leak solution; assuming prefix /AS path filters aren’t doing job adequately) --- Vulnerable to accidental and malicious route leaks --- Let us say 99% are accidental and 1% malicious (you can substitute your numbers) | | \/ BGP with proposed route leak solution (without bgpsec) --- Detects/mitigates the 99% but not the 1% | | \/ Proposed route leak solution with bgpsec --- Detects/mitigates the 99% as well as the 1% Sriram ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
[sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard
The IESG has received a request from the Secure Inter-Domain Routing WG (sidr) to consider the following document: - 'Resource Public Key Infrastructure (RPKI) Trust Anchor Locator' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-07-23. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). This document obsoletes RFC6490 by adding support for multiple URIs in a TAL. A down reference exists in this document by using RFC5781 as a Normative Reference. RFC5781 has already been accepted by the community as a down reference and is properly documented in the DOWNREF Registry. The DOWNREF Registry can be accessed via https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ballot/ No IPR declarations have been submitted directly on this I-D. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
