Dear Colleagues,
We'd like to share some of the discussions from JANOG 34 held in
Takamatsu-city, from 17-18 July with over 500 participants.
While our discussions are in Japanese, we believe there are issues in
common with operators outside Japan. An english version of the Summary
Report and a
On (2014-08-29 03:24 +), Fred Baker (fred) wrote:
Do you implement RPKI? Are providers that neighbor with them implementing
RPKI?
I feel RPKI would be much more marketable if vendors would implement 'loose'
mode.
Loose mode would drop failing routes, iff there is covering (i.e. less
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
randy
On Fri, Aug 29, 2014 at 06:25:16PM +0900, Randy Bush wrote:
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
The proposed 'loose' mode protects against unauthorized hole punching
From: Saku Ytti s...@ytti.fi
I feel RPKI would be much more marketable if vendors would implement 'loose'
mode.
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
+10
And it would completely remove false-positive blackholing.
This
Am 29.08.2014 11:25, schrieb Randy Bush:
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
randy
No, as the the more specific route is signed and is preferred (longest
match routing)
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
No, as the the more specific route is signed and is preferred (longest
match routing) against the less specific hijacked route
clearly i
Am 29.08.2014 11:39, schrieb Randy Bush:
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
No, as the the more specific route is signed and is preferred (longest
match routing) against the
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
No, as the the more specific route is signed and is preferred (longest
match routing) against the less specific hijacked route
clearly i
On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote:
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
No, as the the more specific route is signed and is preferred (longest
On Aug 29, 2014, at 6:08 AM, Job Snijders j...@instituut.net wrote:
On Fri, Aug 29, 2014 at 06:39:32PM +0900, Randy Bush wrote:
Loose mode would drop failing routes, iff there is covering (i.e. less
specific is ok) route already in RIB.
isn't that exactly the hole punching attack?
No, as
On Fri, Aug 29, 2014 at 06:17:09AM -0400, Sandra Murphy wrote:
Loose mode A would look like this:
In the case that 10.0.0.0/16 origin AS123 is not in your table, the
loose mode would kick in and one could accept more specifics for
10.0.0.0/16, but only when originated by AS123.
On (2014-08-29 18:39 +0900), Randy Bush wrote:
clearly i am missing something. got a write-up?
Job got to it, but shortly:
Loose mode RPKI:
- verified or unknown less-specific route is preferable to failing
more-specific
The main goal is always to have all routes, never to blackhole,
On (2014-08-29 14:37 +0300), Saku Ytti wrote:
clearly i am missing something. got a write-up?
Loose mode RPKI:
- verified or unknown less-specific route is preferable to failing
more-specific
Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest
match is not done to
On 8/28/14, 11:28 PM, Mark Andrews ma...@isc.org wrote:
The long term solution is to deploy RPKI and only use
transits which use RPKI. No RPKI support = no business.
Additionally make RPKI a peering requirement.
WG] So should we ask for that before, or after we get everyone
Loose mode A B came into existence 15 minutes ago, its good to
discuss what a loose mode could mean. ;-)
i am ENOTIME. when you have a simple spec i can follow, i would really
look forward to it.
randy
The long term solution is to deploy RPKI and only use
transits which use RPKI. No RPKI support = no business.
Additionally make RPKI a peering requirement.
WG] So should we ask for that before, or after we get everyone to roll
out IPv6 everywhere by voting with our wallets?
considering that
Greetings,
Can someone from GoDaddy please contact me off list? Two of our name servers
have been block from making DNS lookups against your hosted domains.
Many Thanks,
--
Ronald D'Alleva
Email: rdall...@constantcontact.commailto:rdall...@constantcontact.com
On 8/29/14, 9:08 AM, Randy Bush ra...@psg.com wrote:
considering that measured rpki registration (which has a very tragic
side) is ten time ipv6 penetration, i think we ask for rpki first.
WG] I guess I should know better than to ask rhetorical questions on
NANOG, lest I get an answer.
The
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.
Daily listings are sent to
On Friday, August 29, 2014, Randy Bush ra...@psg.com wrote:
i am ENOTIME. when you have a simple spec i can follow, i would really
look forward to it.
Thanks for summing up in a few words how most of us outside your ivory
tower feel about RPKI.
Now if you'll excuse me, I'm a grown-up with
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
registrations.
Matthew Kaufman
(Sent from my iPhone)
On Aug 28, 2014, at 8:28 PM, Mark Andrews ma...@isc.org wrote:
See whois -r AS43239.
The long term solution is to deploy RPKI and only use
transits which
This report has been generated at Fri Aug 29 21:14:09 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
BGP Update Report
Interval: 21-Aug-14 -to- 28-Aug-14 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS38197 213766 4.0% 239.4 -- SUNHK-DATA-AS-AP Sun Network
(Hong Kong) Limited,HK
2 -
apologies. that was meant to be private. sigh.
randy
Matthew Kaufman matt...@matthew.at writes:
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
registrations.
I'd assume that it would be included in your annual LRSA maintenance
fees.
-r
On Fri, Aug 29, 2014 at 06:39:07PM -0400, Robert E. Seastrom wrote:
Matthew Kaufman matt...@matthew.at writes:
I look forward to the ARIN fee schedule for legacy IPv4 holder RPKI
registrations.
I'd assume that it would be included in your annual LRSA maintenance
fees.
Make
What we noticed on home RoadRunner and on business TWC fiber about 6:15 AM EDT
on the 27th:
We could access systems from one to another by IP address but not DNS.
We could ping other systems by IP.
Home DHCP was up but TWC DNS was down at home and at work on the business
fiber. Couldn't even
28 matches
Mail list logo
