Re: maximum ipv4 bgp prefix length of /24 ?

[Willy Manga]

> On 11/10/2023 03:52, Delong.com wrote:



On Oct 10, 2023, at 13:36, Matthew Petach  wrote:
[...]
Owen,

RPKI only addresses accidental hijackings.
It does not help prevent intentional hijackings.


OK, but at least they can help limit the extent of required desegregation in 
combat unless I misunderstand the whole MAXPREFIXLEN option.


Actually, RFC 9319 do recommend to "avoid using the maxLength attribute 
in ROAs except in some specific cases". But I recognise that this RFC is 
not yet implemented everywhere.





RPKI only asserts that a specific ASN must originate a prefix.  It does nothing 
to validate the authenticity of the origination.


Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix 
length”.

E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum 
Length” attribute of /36, then any advertisement (even originated by 65500) 
that is longer than /36 should be considered invalid.


Yes, but in that scenario any advertisements between /32 and /36 from 
that prefix originated by AS65500 are *valid* . That's why "ROAs should 
be as precise as possible, meaning they should match prefixes as 
announced in BGP" [1]


1. 
https://rpki.readthedocs.io/en/latest/rpki/securing-bgp.html#maximum-prefix-length




--
Willy Manga
@ongolaboy
https://ongola.blogspot.com/


OpenPGP_signature.asc
Description: OpenPGP digital signature

APRICOT 2024: Call for Presentations

[Mark Tinka]

APRICOT 2024
21st February - 1st March, Bangkok, Thailand
https://2024.apricot.net

CALL FOR PRESENTATIONS
=

The APRICOT 2024 Programme Committee is now seeking contributions for 
Presentations and Tutorials for the APRICOT 2024 Conference.


We are looking for presenters who would:

- Offer a technical tutorial on an appropriate topic;
- Participate in the technical conference sessions as a speaker;
- Convene and chair panel sessions of relevant topics;
- Lead informal Birds of Feather break out sessions.

Please submit on-line at:

https://papers.apricot.net/user/login.php?event=186

CONFERENCE MILESTONES
--

Call for Papers Opens:       Now
Outline Programme Published:    As Papers Confirmed
Final Deadline for Submissions:  29th January 2024
Final Program Published:            5th February 2024
Final Slides Received:                19th February 2024

*SLOTS ARE FILLED ON A FIRST COME, FIRST SERVED BASIS, REGARDLESS OF 
PUBLISHED DEADLINES*


PROGRAMME CONTENT
-

The APRICOT Conference Programme consists of three parts, these being 
Tutorials, the Peering Forum, and Conference Sessions.


Topics proposed must be relevant to Internet Operations and 
Technologies, for example:


- IPv4 / IPv6 Routing and Operations
- Routing Security, including RPKI and MANRS
- Internet backbone operations
- Peering, Interconnects and IXPs
- Content Distribution Network technology & operations
- Research on Internet Operations and Deployment
- Network Virtualisation
- Network Automation/Programming
- Network Infrastructure security
- IPv6 deployment on fixed and Wireless/Cellular networks
- DNS / DNSSEC and KINDNS
- Access and Transport Technologies
- Technical application of Web 3.0, public blockchains and cryptocurrency
- Content & Service Delivery and "Cloud Computing"
- 400G ZR, ZR+ & Open ROADM
- Submarine cables
- ChatGPT

CfP SUBMISSION
-

Draft slides for both tutorials and conference sessions MUST be provided 
with CfP submissions otherwise the submission will be rejected 
immediately. For work in progress, the most current information 
available at the time of submission is acceptable.


All draft and complete slides must be submitted in PDF format only. 
Slides must be of original work, with all company confidential marks 
removed.


Any marketing, sales and vendor proprietary content in a presentation is 
against the spirit of APRICOT and it is strictly prohibited.


Note that proper credit must be given for all content taken from other 
sources. Evidence of plagiarism is grounds for rejection.


Final slides are to be provided by the specified deadline for 
publication on the APRICOT website.


Prospective presenters should note that the majority of speaking slots 
will be filled well before the final submission deadline. The PC may, at 
their discretion, retain a limited number of slots up to the final 
submission deadline for presentations that are exceptionally timely, 
important, or of critical operational importance. Every year we turn 
away submissions, due to filling up all available programme slots before 
the deadline. Presenters should endeavour to get material to the PC 
sooner rather than later.


Any questions or concerns should be addressed to the Programme Committee 
Chairs by e-mail at:


    pc-chairs at apricot.net

We look forward to receiving your presentation proposals.

Mark Tinka, Achie Atienza & Mark Duffell
APRICOT 2024 Programme Committee Chairs
--

Re: FastNetMon Usage in the wild

[Mark Tinka]

On 10/11/23 04:34, Dobbins, Roland via NANOG wrote:


To clarify, Sightline has supported virtualization for many years, FYI.


It does do, yes. But pricing for the software license is not too far off 
from if you chose to buy Netscout's own hardware.


Not a major drama for me - I appreciate that competence has to be 
compensated. What I am saying is that attempts to make it more palatable 
to more operators are not making too much of a dent.


Mark.

Re: xfinity not working

[Al Whaley]

My understanding is that the internal web page in the consumer modems is 
gone.  App or nothing.


I don't think the options one could set from the web login are there 
anymore either, though I haven't bothered to confirm that myself.


Gotta love it.

The business modems still have internal web pages.  Maybe they're next?

Therefore your experience is nominal.

On 10/10/2023 15:26, William Herrin wrote:

Howdy,

Wondering if any of the folks from Xfinity have tried activating
internet service with their own modem and without installing a mobile
phone app any time in the recent past. It doesn't work. It just
doesn't work.

http://www.xfinity.net/activate  ->
https://idm.xfinity.com/myaccount/account-selector?execution=e4s1  ->
https://login.xfinity.com/login

Access Denied
You don't have permission to access "http://login.xfinity.com/login?;
on this server.

Regards,
Bill Herrin

Re: FastNetMon Usage in the wild

[Dobbins, Roland via NANOG]

On 11 Oct 2023, at 01:50, Adam Thompson  wrote:

you need to buy a moderately-expensive hardware server (they don’t let you 
virtualize it)

To clarify, Sightline has supported virtualization for many years, FYI.

 I’m not aware of any anti-DDoS products at ISP scale that aren’t SFlow + 
Flowspec, possibly including “scrubbing” (diverter box);

 I don’t know if it’s an in-band appliance, or a “scrubber”-on-a-stick

In addition to flow telemetry, D/RTBH, S/RTBH, and flowspec, Sightline/TMS 
supports intelligent DDoS mitigation directly in-line or via 
diversion/reinjection.

[Full disclosure:  I am an employee of NETSCOUT.]

Re: xfinity not working

[Crist Clark]

I had a forced modem upgrade with them earlier this year. I vaguely recall
it was not without some frustration, but I managed to get it done.

I don’t seem to have a problem logging in at
https://login.xfinity.com/login
Is it transient or still persisting for you?


On Tue, Oct 10, 2023 at 5:07 PM Delong.com via NANOG 
wrote:

> I didn’t have a problem with it a couple of months ago, but that was when
> I installed Comcast Business, so likely a different user experience from
> residential. I had to call them on the phone to turn off my residential
> after the business install was completed and operational.
>
> Owen
>
>
> > On Oct 10, 2023, at 15:26, William Herrin  wrote:
> >
> > Howdy,
> >
> > Wondering if any of the folks from Xfinity have tried activating
> > internet service with their own modem and without installing a mobile
> > phone app any time in the recent past. It doesn't work. It just
> > doesn't work.
> >
> > http://www.xfinity.net/activate  ->
> > https://idm.xfinity.com/myaccount/account-selector?execution=e4s1  ->
> > https://login.xfinity.com/login
> >
> > Access Denied
> > You don't have permission to access "http://login.xfinity.com/login?;
> > on this server.
> >
> > Regards,
> > Bill Herrin
> >
> > --
> > William Herrin
> > b...@herrin.us
> > https://bill.herrin.us/
>
>
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Andrews]

> On 11 Oct 2023, at 09:43, Delong.com via NANOG  wrote:
> 
>> As a community, we have failed, because we never acknowledged and addressed 
>> the need for backward compatibility between IPv6 and IPv4, and instead 
>> counted on magic handwaving about tipping points and transition dates where 
>> suddenly there would be "enough" IPv6-connected resources that new networks 
>> wouldn't *need* IPv4 address space any more.
> 
> I’m not sure that we never acknowledged it, but we did fail to address it, 
> largely because I think we basically determined that it’s “too hard”.

It’s not actually that hard to do on a small scale, i.e. inside a home CPE with 
a DNS server and a NAT64 implementation that supports semi static mappings.  It 
does require IPv4 sites have IPv6 connectivity. You stand up a DNS46 which 
requests an unused IPv4 address from a prefix block, say 10/8, when there is an 
IPv6 address without an IPv4 address from the NAT64 with the IPv6 address it 
needs to be mapped to with an initial NAT64 lifetime value.  The DNS46 would 
forget the mapping after half that initial lifetime.  The DNS46 would return A 
records limited half the lifetime or less so they timeout before the NAT64 
mapping expires.  The hard part is scaling up to a large client base because 
not every DNS query results in IP traffic and you need a prefix block big 
enough to support the add rate of the client base.  Doing this at ISP scale 
would be interesting to say the least.  This is not theoretical.  It has been 
implemented in the past though some to the details might differ.

Companies that have gone IPv6-only internally do this with fully static IPv4 to 
IPv6 mappings and skip the DNS46 step.

So if you have a legacy device that can’t talk IPv6 there is a solution space 
that allows it to talk to the IPv6 internet.  You need to install it however.  
Adding DNS46 to a nameserver is about a days if you already have a DNS64 model. 
 The hard bit is working out how to talk to the NAT64 implementation.  A good 
project to put on a Raspberry Pi or similar.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: xfinity not working

[Delong.com via NANOG]

I didn’t have a problem with it a couple of months ago, but that was when I 
installed Comcast Business, so likely a different user experience from 
residential. I had to call them on the phone to turn off my residential after 
the business install was completed and operational.

Owen


> On Oct 10, 2023, at 15:26, William Herrin  wrote:
> 
> Howdy,
> 
> Wondering if any of the folks from Xfinity have tried activating
> internet service with their own modem and without installing a mobile
> phone app any time in the recent past. It doesn't work. It just
> doesn't work.
> 
> http://www.xfinity.net/activate  ->
> https://idm.xfinity.com/myaccount/account-selector?execution=e4s1  ->
> https://login.xfinity.com/login
> 
> Access Denied
> You don't have permission to access "http://login.xfinity.com/login?;
> on this server.
> 
> Regards,
> Bill Herrin
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

> On Oct 10, 2023, at 13:36, Matthew Petach  wrote:
> 
> 
> 
> On Tue, Oct 10, 2023 at 12:58 PM Delong.com via NANOG  > wrote:
>> Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can 
>> specify the maximum prefix length allowed to be advertised within a shorter 
>> prefix and those (theoretically) block hijackers taking advantage of 
>> advertising more specifics to cut you off?
>> 
>> While I recognize that RPKI is not ubiquitous, enough of the major backbones 
>> are dropping RPKI invalids that I think any sort of hijacking in violation 
>> of that wouldn’t be very effective today.
>> 
>> YMMV of course, but that seems to me to be a far better solution (almost 
>> enough to make me rethink the questionable value of RPKI) than 
>> disaggregation.
>> 
>> Owen
> 
> Owen,
> 
> RPKI only addresses accidental hijackings.
> It does not help prevent intentional hijackings. 

OK, but at least they can help limit the extent of required desegregation in 
combat unless I misunderstand the whole MAXPREFIXLEN option.

> 
> RPKI only asserts that a specific ASN must originate a prefix.  It does 
> nothing to validate the authenticity of the origination.

Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix 
length”.

E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum 
Length” attribute of /36, then any advertisement (even originated by 65500) 
that is longer than /36 should be considered invalid.

> If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs 
> protecting it, and AS YY has allowed more specifics to be announced within 
> the prefix range covered by the ROA, I'm in like flynn, because I just need 
> to configure my router with AS YY as the origin AS, then insert the expected 
> ASN for the neighbor adjacency with my upstreams, and bob's your uncle, the 
> more specific prefix passes RPKI validation, and traffic comes flying my way.

Yes, IF YY has allowed longer prefixes. If YY doesn’t allow longer prefixes 
and/or doesn’t supply AS0 ROAs for more specifics that should not be announced, 
then YY has indeed aimed a firearm squarely at their lower distal appendage and 
fired.

However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as 
well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY 
would generate ROAs for
2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36
2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed)
2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36

> If AS YY doesn't allow longer prefixes within the scope of their ROA, then 
> it's a bit dicier, because it comes down to AS-PATH length, but there's still 
> a good chance you can suck in traffic from your adjacent neighbors.

Sure, but that’s true if the hijacker is willing to disaggregate down to 
whatever your MAXPREFIXLEN is, no matter what, even if that’s /48. At least 
this allows the AS owner to set some desegregation floor where the more 
specific battle ends short of /48.

> So yes, hijackings in violation of RPKI aren't as effective, but RPKI doesn't 
> prevent intentional hijackings--it just protects against accidental 
> misconfigurations and unintentional hijackings.

Oh, you don’t have convince me on that one. I’ve long said “RPKI offers little 
more than a cryptographically signed hint as to what hijackers need to prepend 
to their announcements.”.

> Thus, deaggregation is still very much part of the defensive toolbox, even 
> with RPKI in place.

Yes, but RPKI properly used does allow one to limit the extent of the 
deaegregation battle.

> As a side note, it's also a really good reason why you shouldn't allow longer 
> prefixes to be announced under your ROAs, except under very well understood 
> conditions.   ^_^;

Right… AND add AS-0 ROAs for any more specifics you don’t want announced.

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

> 
> The questions you ask Owen are obviously answerable by anyone with access to 
> a BGP routing table dump (which is pretty much anyone!).
> 
> BGP is many things - it is a topology maintenance protocol, but its a traffic 
> engineering protocol and an attack mitigation protocol. In the latter two 
> cases advertising more specifics play a crucial role. The pressure to slice 
> and dice in IPv4 is a mix of reachability in a space where address 
> availability is under acute pressure, and TE and DOS mitigation. The 
> pressures on IPv6 are predominately from the latter two categories. I suspect 
> that as IPv6 becomes a larger part of the traffic mix (and inexorably that 
> appears to be happening) then the TE and DOS issues become more of an 
> operational concern, hence rising more specifics in IPv6. 
> 

I think a certain amount of desegregation for TE is inevitable and will always 
be part of the system.

At least theoretically, DDOS mitigation specifics should be relatively 
transient in nature and anti-hijacking more specifics should be solved by RPKI 
max prefix length attributes in ROAs.

I guess it’s maybe good news that IPv6 rollout is happening faster than RPKI 
rollout, but IPv6 rollout is still way too slow. There is, however, recent very 
good news on that front:

owendelong@PK9XYF9GRK-1346 ~ % host www.amazon.com
www.amazon.com is an alias for tp.47cf2c8c9-frontier.amazon.com.
tp.47cf2c8c9-frontier.amazon.com is an alias for d3ag4hukkh62yn.cloudfront.net.
d3ag4hukkh62yn.cloudfront.net has address 108.138.248.64
d3ag4hukkh62yn.cloudfront.net has IPv6 address 
2600:9000:24bb:fe00:7:49a5:5fd2:8621
d3ag4hukkh62yn.cloudfront.net has IPv6 address 
2600:9000:24bb:2400:7:49a5:5fd2:8621
d3ag4hukkh62yn.cloudfront.net has IPv6 address 
2600:9000:24bb:5e00:7:49a5:5fd2:8621
d3ag4hukkh62yn.cloudfront.net has IPv6 address 
2600:9000:24bb:7600:7:49a5:5fd2:8621
d3ag4hukkh62yn.cloudfront.net has IPv6 address 
2600:9000:24bb:7800:7:49a5:5fd2:8621
d3ag4hukkh62yn.cloudfront.net has IPv6 address 
2600:9000:24bb:ae00:7:49a5:5fd2:8621
d3ag4hukkh62yn.cloudfront.net has IPv6 address 
2600:9000:24bb:b600:7:49a5:5fd2:8621
d3ag4hukkh62yn.cloudfront.net has IPv6 address 
2600:9000:24bb:f000:7:49a5:5fd2:8621

I don’t know how deep into the Amazon process that goes or if it’s possible to 
actually browse Amazon and complete an order without IPv4 yet, but this is at 
least significant progress from one of the biggest barriers to IPv6-only that 
remained a few years ago.

Yes, I could get the answers from my own table dumps, even, but I would have to 
find/build the necessary analysis tools to crunch the almost 1M prefix tables 
to extract that information and even beyond that, attempting to infer the cause 
becomes an even more interesting challenge (as you not only well know, but
have expressed in some of your rather excellent presentations on the subject in 
past years).

At the moment, the things that pay the bills have higher priorities for my time 
than delving into these questions that deeply.

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

> As a community, we have failed, because we never acknowledged and addressed 
> the need for backward compatibility between IPv6 and IPv4, and instead 
> counted on magic handwaving about tipping points and transition dates where 
> suddenly there would be "enough" IPv6-connected resources that new networks 
> wouldn't *need* IPv4 address space any more.

I’m not sure that we never acknowledged it, but we did fail to address it, 
largely because I think we basically determined that it’s “too hard”.

There’s really no way for a machine with a >32 bit address to feasibly/reliably 
talk to a machine that only understands 32-bit addresses short of involving 
some sort of intermediate proxy host doing some form of address translation. 
We’ve actually got LOTS of those solutions deployed with varying levels of 
success/failure/idiosyncrasies. I’ve spent a fair amount of time thinking about 
alternatives and admit that I, myself am stumped as to how one would go about 
this.

> In doing so, we have sown the seeds of our own future pain and suffering.

Do you have a proposal for how this problem could have been/could be solved?

> By allowing IPv6 to be defined and established as an incompatible network 
> protocol to IPv4, we ensured that IPv4's future was assured.

I’d argue that we did much more to achieve that by deploying NAT. Absent NAT, 
we wouldn’t be able to pretend that IPv4 still works.

> *Every* transition mechanism we have for networks today relies on having 
> *some* amount of IPv4 address space for the translation gateway devices, 
> which will continue to drive an ever-increasing demand for smaller and 
> smaller chunks of IPv4 address space to be parceled out to every new network 
> that wants to join the Internet.

Well, at least theoretically, that can end when a sufficient critical mass of 
the internet is reachable via native IPv6 that we no longer care about reaching 
the outlying corners that aren’t.

Let me ask you a slightly different question… Given a clean slate, what would 
you do differently so that a host with no possible capability to put more than 
32-bits into the source or destination address field of a packet and no ability 
to look for address pieces elsewhere in the packet (i.e. a current IPv4 host 
without software modification) could talk to a host that doesn’t have a 32-bit 
address?

It turns out to be _REALLY_ hard to put more than 32-bits into a 32-bit field 
without loss.

Short of doing that, any translation mechanism is going to require some IPv4 
address for the translation host (though it doesn’t necessarily have to be 
globally unique).

> The only alternative is that web-scale companies like Amazon and Google stand 
> up swaths of IPv6-to-IPv4 translation gateway boxes, and provide 6-to-4 
> bidirectional translation services, with some clever marketing person 
> figuring out how to make money reliably from the service.

I’m not convinced this is the ONLY alternative, but it’s certainly one of the 
(sadly) less impractical ones.

> At that point, new entrants could conceivably get on board the Internet with 
> only IPv6 resources, with no need to scrabble for a chunk of ever-decreasing 
> IPv4 space to perform the necessary gateway translation for their customers.

IPv4 is still relatively cheap at $50/address. The bigger problem, however, is 
that the people who need to migrate aren’t the ones paying the cost of failing 
to migrate. We’ve got an economy where the interests of the community are 
utterly divorced from the interests of those with no motivation to migrate to 
IPv6 and really, no way to provide that motivation through externalization of 
the cost.

I don’t know of a practical way to do it, but if there was some economic cost 
that could be imposed on entities failing to implement IPv6 in their products 
and services, I would be willing to bet that IPv6 uptake among the remaining 
IPv4-only entities would be greatly accelerated. Especially if that cost 
somehow escalated each year they failed to act.

> Unfortunately, because it's not just a mapping problem but an actual 
> packet-level incompatibility, the companies providing the magical 
> bidirectional translation service are going to be in the pathway for the 
> entire bitstream, making it a bandwidth-intensive product to deploy.  :(

Frankly, this almost certainly ends up being something that needs to be 
deployed close to the edge by two classes of entities:

1.  Eyeball ISPs that have customers that can’t go IPv6-only.
2.  Content providers that don’t provide native IPv6.

Again, this comes back to the economic issue I’ve described above. Plenty of 
incentive for 1 and really, that’s no worse than CGNAT and is already being 
done by some, but for 2, so far, at least, that group has been able to 
externalize the costs onto everyone else by forcing them to figure out how to 
continue to preserve access to their IPv4-only content instead of having to 
adopt IPv6.

Since it costs them 

xfinity not working

[William Herrin]

Howdy,

Wondering if any of the folks from Xfinity have tried activating
internet service with their own modem and without installing a mobile
phone app any time in the recent past. It doesn't work. It just
doesn't work.

http://www.xfinity.net/activate  ->
https://idm.xfinity.com/myaccount/account-selector?execution=e4s1  ->
https://login.xfinity.com/login

Access Denied
You don't have permission to access "http://login.xfinity.com/login?;
on this server.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Tue, Oct 10, 2023 at 12:58 PM Delong.com via NANOG 
wrote:

> Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can
> specify the maximum prefix length allowed to be advertised within a shorter
> prefix and those (theoretically) block hijackers taking advantage of
> advertising more specifics to cut you off?
>
> While I recognize that RPKI is not ubiquitous, enough of the major
> backbones are dropping RPKI invalids that I think any sort of hijacking in
> violation of that wouldn’t be very effective today.
>
> YMMV of course, but that seems to me to be a far better solution (almost
> enough to make me rethink the questionable value of RPKI) than
> disaggregation.
>
> Owen
>

Owen,

RPKI only addresses accidental hijackings.
It does not help prevent intentional hijackings.

RPKI only asserts that a specific ASN must originate a prefix.  It does
nothing to validate the authenticity of the origination.

If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs
protecting it, and AS YY has allowed more specifics to be announced within
the prefix range covered by the ROA, I'm in like flynn, because I just need
to configure my router with AS YY as the origin AS, then insert the
expected ASN for the neighbor adjacency with my upstreams, and bob's your
uncle, the more specific prefix passes RPKI validation, and traffic comes
flying my way.

If AS YY doesn't allow longer prefixes within the scope of their ROA, then
it's a bit dicier, because it comes down to AS-PATH length, but there's
still a good chance you can suck in traffic from your adjacent neighbors.

So yes, hijackings in violation of RPKI aren't as effective, but RPKI
doesn't prevent intentional hijackings--it just protects against accidental
misconfigurations and unintentional hijackings.

Thus, deaggregation is still very much part of the defensive toolbox, even
with RPKI in place.

As a side note, it's also a really good reason why you shouldn't allow
longer prefixes to be announced under your ROAs, except under very well
understood conditions.   ^_^;

Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Delong.com via NANOG]

Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can 
specify the maximum prefix length allowed to be advertised within a shorter 
prefix and those (theoretically) block hijackers taking advantage of 
advertising more specifics to cut you off?

While I recognize that RPKI is not ubiquitous, enough of the major backbones 
are dropping RPKI invalids that I think any sort of hijacking in violation of 
that wouldn’t be very effective today.

YMMV of course, but that seems to me to be a far better solution (almost enough 
to make me rethink the questionable value of RPKI) than disaggregation.

Owen


> On Oct 7, 2023, at 05:32, Willy Manga  wrote:
> 
> Hi.
> 
> On 06/10/2023 16:00, nanog-requ...@nanog.org wrote:
>> From: Matthew Petach
>> [...]
>>> The IPv6 FIB is under the same pressure from more specifics. Its taken 20
>>> years to get there, but the IPv6 FIB is now looking stable at 60% opf the
>>> total FIB size [2]. For me, thats a very surprising outcome in an
>>> essentially unmanaged system.
>>> 
>>> 
>>> Were you expecting it to be lower than IPv4?
>>> 
>>> Mark.
>>> 
>> I've dug through the mailman mirror on nanog.org, and there's currently no
>> post by Geoff Huston saying that:
>> https://community.nanog.org/search?q=geoff%20huston%20order%3Alatest
> 
> I read (and send) NANOG emails through the digest emails sent once a day. I 
> noticed the same thing . I assumed it was sent directly to Mark (or the mail 
> will enter my next digest...)
> 
> 
>> But I'll play along.
>> There's significantly less pressure to deaggregate IPv6 space right now,
>> because we don't see many attacks on IPv6 number resources.
>> Once we start to see v6 prefix hijackings, /48s being announced over /32
>> prefixes to pull traffic, then I think we'll see IPv6 deaggregation
>> completely swamp IPv4 deaggregation.
> 
> How about we educate each other to not assume you must deaggregate your 
> prefix especially with IPv6?
> 
> I see 'some' (it's highly relative) networks on IPv4, they 'believe' they 
> have to advertise every single /24 they have. And when they start with IPv6, 
> they replicate the same mindset with a tons of /48 . You can imagine what 
> will happen of course.
> 
> A better alternative IMHO is to take advantage to the large prefix range and 
> advertise a sub-aggregate when necessary. But absolutely not each end-node or 
> customer prefix.
> 
> 
> -- 
> Willy Manga
> @ongolaboy
> https://ongola.blogspot.com/

RE: FastNetMon Usage in the wild

[Adam Thompson]

We use Arbor’s Sightline in an SFlow + Flowspec topology.  It… works.  It needs 
a lot of tuning.  It’s moderately expensive to deploy in this topology, unlike 
in-band which is holy-cow-expensive at our speeds.  If you want 
historical/forensic data, you need to buy a moderately-expensive hardware 
server (they don’t let you virtualize it) for their Insight module.  Arbor’s 
tech support is Quite Good Indeed, and their SE team is FANTASTIC.  Sales, 
however, not so much.  We don’t feel Sightline is doing all that much for us, 
but we also aren’t able to put the required amount of daily care and feeding 
into it that it needs, so YMMV.

My overall impression is that all the on-prem anti-DDOS products out there do 
the same thing, and work much the same way – thresholds, hopefully with 
auto-baselining.  The differentiating factors IMHO are whether the 
auto-baselining can take time-of-day, day-of-week, and month into account (e.g. 
business day, K-12 school year, etc.); we believe Sightline’s auto-baselining 
doesn’t do a great job here.  Beyond that, any product that uses an evolving 
statistical model (probably branded as “AI”, sigh) will have a slightly better 
chance of improving the successful hit ratio.

I’m not aware of any anti-DDoS products at ISP scale that aren’t SFlow + 
Flowspec, possibly including “scrubbing” (diverter box); having said that, I do 
know one of my upstreams has a large Sightline h/w appliance of some sort, I 
don’t know if it’s an in-band appliance, or a “scrubber”-on-a-stick, but it’s 
too expensive for them to upgrade and they’re apparently dropping it instead… 
once we stop telling them quite so loudly to NOT get rid of it , I guess??

AFAIK, FastNetMon is basically the same thing as Sightline, with a 
less-polished UI. (read: doesn’t make mgmt. as happy to look at it) and you 
need some external support bits to do the Flowspec.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[cid:image001.png@01D9FB80.2D14BDE0]
100 - 135 Innovation Drive
Winnipeg, MB R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
https://www.merlin.mb.ca
[cid:image002.png@01D9FB80.2D14BDE0]Chat with me on 
Teams


From: NANOG  On Behalf Of 
Javier Gutierrez
Sent: Friday, October 6, 2023 5:20 PM
To: nanog@nanog.org
Subject: FastNetMon Usage in the wild

Hi,
I wanted to drop a quick question as I would like to evaluate the FastNetMon 
solution to do DDoS protection and wanted to see what other companies are using 
it out there so I can have a base of how much should I recommend this.

Thanks in advance for your responses


Kind regards,


Javier Gutierrez,

Re: AT Business Center completely broken for months - is it the norm?

[TJ Trout]

it's related to cookies, also if your getting a BC login your probably
paying too much (use wholesale)

On Tue, Oct 10, 2023 at 10:33 AM TJ Trout  wrote:

> use incognito mode
>
> On Mon, Oct 9, 2023 at 10:44 PM Daniel Marks via NANOG 
> wrote:
>
>> This has been the case with most AT systems I’ve had to use in the past
>> 5 years, FirstNet is even worse. As others suggested in trying different
>> browsers, I found that a lot of (especially older) corporate firewalls just
>> seem to hate AT websites and flipping on a VPN to  tends
>> to resolve most of my issues.
>>
>> -Dan
>>
>> > On Oct 9, 2023, at 23:41, Mirai Azayaka  wrote:
>> >
>> > Hi NANOG,
>> >
>> > Maybe this topic is better suited for the complaint department of AT
>> > but I just want to confirm if it's just me or it's just AT
>> >
>> > So I'm a new customer of AT's DIA network and I haven't been able to
>> > make a payment since day one. (And it has been several months.) Just
>> > wondering if a completely broken internal billing system is normal...
>> > I only have limited experience with Hurricane Electric and Equinix
>> > before. Wondering if Verizon or Comcast is also broken like AT Here
>> > are the issues I had with their system:
>> > - Clicking random links around the portal will give you HTTP 400
>> > errors, sometimes.
>> > - I'm unable to add payment methods even after following the payment
>> > tutorial exactly. The portal consistently gives HTTP 413 errors.
>> > - Live chat doesn't work at all. Clicking the button returns HTTP 404
>> > in my debugging console.
>> > - Extremely slow for some tasks which may result in a HTTP 408.
>> >
>> > The system feels like a collection of HTTP error codes... How can it
>> > be so broken? Are other ISP's internal billing systems broken like
>> > this? Looking for anecdotes / experiences.
>> >
>> > Azayaka
>>
>

Re: AT Business Center completely broken for months - is it the norm?

[TJ Trout]

use incognito mode

On Mon, Oct 9, 2023 at 10:44 PM Daniel Marks via NANOG 
wrote:

> This has been the case with most AT systems I’ve had to use in the past
> 5 years, FirstNet is even worse. As others suggested in trying different
> browsers, I found that a lot of (especially older) corporate firewalls just
> seem to hate AT websites and flipping on a VPN to  tends
> to resolve most of my issues.
>
> -Dan
>
> > On Oct 9, 2023, at 23:41, Mirai Azayaka  wrote:
> >
> > Hi NANOG,
> >
> > Maybe this topic is better suited for the complaint department of AT
> > but I just want to confirm if it's just me or it's just AT
> >
> > So I'm a new customer of AT's DIA network and I haven't been able to
> > make a payment since day one. (And it has been several months.) Just
> > wondering if a completely broken internal billing system is normal...
> > I only have limited experience with Hurricane Electric and Equinix
> > before. Wondering if Verizon or Comcast is also broken like AT Here
> > are the issues I had with their system:
> > - Clicking random links around the portal will give you HTTP 400
> > errors, sometimes.
> > - I'm unable to add payment methods even after following the payment
> > tutorial exactly. The portal consistently gives HTTP 413 errors.
> > - Live chat doesn't work at all. Clicking the button returns HTTP 404
> > in my debugging console.
> > - Extremely slow for some tasks which may result in a HTTP 408.
> >
> > The system feels like a collection of HTTP error codes... How can it
> > be so broken? Are other ISP's internal billing systems broken like
> > this? Looking for anecdotes / experiences.
> >
> > Azayaka
>