Home page logo
/
nanog logo
NANOG Mailing List

The North American Network Operators' Group discusses fundamental Internet infrastructure issues such as routing, IP address allocation, and containing malicious activity.

List Archives

JanFebMarAprMayJunJulAugSepOctNovDec
201469289910418856815401015498
20139311007824690546937545595624578509828
20121239136711786027191107891774953681879697
201117892122102980296214596058871148802976993
20101136120613051611652663813933997133910811476
2009940125455210198256277507016461105884956
20088476506057507398127507961027536628716
20078064575056937626525427645721023355299
2006691674660448403552379551630567310327
200582461991512047906321075104810851237769593
2004852100411828917851220752770848537999768
20031099692986875676683633152915791527757675
2002468533556737117197911231097815714735575
2001108894910528221145105680011501956857518382
2000468684338498539617716497634323651550
1999436304372340271227244312246447326438
19984046334315768627962856297541063967402
19977205075764867966131120525608589843342
19963642132754962902333493339031099373290
1995947419126717125150253251210391140
199416144593349116845452

Latest Posts

Re: Prefix hijacking, how to prevent and fix currently Saku Ytti (Aug 29)
Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest
match is not done to whole population, population is first divided to
'verified', 'unknown' and 'failed' routes, and longest match is done for each
sub-population in order, until match is found.

Re: Prefix hijacking, how to prevent and fix currently Saku Ytti (Aug 29)
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, prefering bad
route over no route.

Re: Prefix hijacking, how to prevent and fix currently Job Snijders (Aug 29)
Correct.

Sorry, with "not invalid" i meant "valid".

I'd like to accept more-specifics, only in the absense of the
less-specific ROA covered prefix.

The less specific has to have a ROA, for any loose mode to make sense.

Loose mode A & B came into existence 15 minutes ago, its good to discuss
what a loose mode could mean. ;-)

Kind regards,

Job

Re: Prefix hijacking, how to prevent and fix currently Sandra Murphy (Aug 29)
In your examples, you presume there's a ROA for the less-specific.

Here you say "not invalid", which would mean a route that is "unknown", i.e. no ROA exists.

Your Loose Mode A relies on the existence of the ROA - you accept more specifics but only when originated by the ASN in
the ROA.

So which do you mean? The less specific has a ROA or the less specific may not have a ROA?

(Just trying to work this out in my...

Re: Prefix hijacking, how to prevent and fix currently Job Snijders (Aug 29)
I'll attempt to clarify.

Assume:

ROA: 10.0.0.0/16, max_length = 16, origin = AS123
in RIB: 10.0.0.0/16 origin AS123 (valid)

With the above two conditions any updates containing more-specifics
of 10.0.0.0/16 would be rejected/not-installed, just like in todays
'strict mode'

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

Re: Prefix hijacking, how to prevent and fix currently Randy Bush (Aug 29)
been around this a few times. no magic pill found. would love to learn
of one. but one either wants to stop mis-originations or not.

but i would like to see an actual write-up of this 'loose mode' and
terse would be fine, heck preferred. :)

randy

Re: Prefix hijacking, how to prevent and fix currently Karsten Thomann (Aug 29)
Am 29.08.2014 11:39, schrieb Randy Bush:

sorry my mistake, you're right

Re: Prefix hijacking, how to prevent and fix currently Randy Bush (Aug 29)
clearly i am missing something. got a write-up?

randy

Re: Prefix hijacking, how to prevent and fix currently Karsten Thomann (Aug 29)
Am 29.08.2014 11:25, schrieb Randy Bush:

No, as the the more specific route is signed and is preferred (longest
match routing) against the less specific hijacked route

Re: Prefix hijacking, how to prevent and fix currently Brandon Butterworth (Aug 29)
+10

This is why I don't want strict. That and true-positives, I don't think
having a switch that allows courts/rir finger trouble etc to take out
global routing is sensible. Too many others would start using it.

However loose mode could be abused in the same way, they just
invalidate your key and advertise a covering route to give themselves
effective strict over you. Admittedly there is collateral damage to
adjacent address space...

Re: Prefix hijacking, how to prevent and fix currently Job Snijders (Aug 29)
The proposed 'loose' mode protects against unauthorized hole punching

Re: Prefix hijacking, how to prevent and fix currently Randy Bush (Aug 29)
isn't that exactly the hole punching attack?

randy

Re: Prefix hijacking, how to prevent and fix currently Saku Ytti (Aug 29)
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.
This mode would protect from routed hijacks, but not from non-routed hijacks,
which are less serious. And it would completely remove false-positive
blackholing.

There is very small incentive for SP to deploy RPKI, since user-error in
far-end,...

JANOG 34 Meeting Report MAWATARI Masataka (Aug 29)
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 report on anti-spam measures session is be made available
this time, below.

JANOG 34 Summary Report and "Let's talk about IP...

Re: Prefix hijacking, how to prevent and fix currently Mark Andrews (Aug 29)
See "whois -r AS43239".

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.

Mark

In message <CAAjbWEr_o+yQY1T72JMvJ_Nw2Eu2L7=TzZ0dc33mhodo5JB=yw () mail gmail com>
, Tarun Dua writes:

More Lists

Dozens of other network security lists are archived at SecLists.Org.


[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]