Re: Advantages and disadvantages of legacy assets

[Rubens Kuhl]

On Mon, Nov 20, 2023 at 4:15 PM Lukas Tribus  wrote:
>
> On Mon, 20 Nov 2023 at 20:08, Rubens Kuhl  wrote:
> >
> > You can get IRR from RADB or AltDB.
>
> Which is not going to be useful forever ... see [1]:
>
> > Please note that 'route' and 'route6' objects created after 2023-Aug-15
> > in non-authoritative registries like RADB, NTTCOM, ALTDB won't be
> > processed.
>
>
>
>
> [1] https://lg.as6453.net/doc/cust-routing-policy.html

First time I see a Tier-1 complaining about non-authoritative IRR. I
wonder what they do with IRR sources that do validate although not
being run by a RIR/NIR, like TC.


Rubens

Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks

[Amir Herzberg]

Tom, thanks for the feedback! We will try to avoid giving the impression
that BGP-iSec is a working solution or to oversell it otherwise; sometimes,
when one writes about a design, such `selling-speach' crawls in
without invitation or intention :)

So, I've rephrased  "relatively easy to implement" to something which would
hopefully not be misleading, and added a bit in conclusions and intro to
try to clarify that more research is needed, pointing out several
directions. We'll try to find more places where we it may be desirable to
clarify this; if you (or others) have more specific examples, that would be
appreciated.

Thanks again, Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/cybersecurity




On Mon, Nov 20, 2023 at 12:41 PM Tom Beecher  wrote:

> Amir-
>
> I have to take some issue with one comment you made in response to Job.
>
> BGP-iSec, at this point, is just an academic study studying some new ideas
>> and evaluating their impact in specific configurations, under specific
>> assumptions etc.; hopefully, this may provide some help to the community in
>> improving BGP security.
>>
>
> When reviewing the paper , it feels as if BGP-iSec is being presented as a
> working solution, not just ideas and theoretical analysis. Care should be
> taken not to oversell the status of a thing; that just leads to confusion
> and issues later.
>
> Also, as an aside, when most network engineers read statements that
> something is "relatively easy to implement", large red lights start going
> off in our brains; If we had $1 for every time we heard that and it turned
> out to be false, we'd all pretty much be retired. :)
>
>
>
>
>
>
>
>
> On Mon, Nov 20, 2023 at 10:45 AM Amir Herzberg 
> wrote:
>
>> Lancheng, thanks for your comment.
>>
>> About ProConi (and ASPA): so, we're aware it's more challenging than ASPA
>> and have evaluated the effort required - it actually doesn't seem too bad,
>> although that doesn't mean that it'll be cost effective to use it. But as
>> I've mentioned in an earlier email to this list, Joel Halpern (cc:ed) has
>> alerted us to an even larger problem with ProConi; the proconi list of a
>> given AS may become incorrect due to certain changes in AS relationships,
>> leading to possible false-positives for possibly significant time. This is
>> obviously very problematic and we are editing this part of the paper to
>> reflect this risk. Probably, this mechanism should not be deployed;
>> luckily, we obtained good results also with the other defenses against
>> leakage in the paper, for the practical case of non-eavesdropping
>> adversary. In any case we see the work as the opening point, or another
>> step, toward more effective defenses against path manipulations and
>> intentional route leaks. More work should be done.
>>
>> We look forward to meeting you in NDSS; I haven't yet seen list of
>> accepted papers, and it'll be great if you can share your paper. But if
>> not, then we'll see it in the conference :)
>>
>> best, Amir
>> --
>> Amir Herzberg
>>
>> Comcast professor of Security Innovations, Computer Science and
>> Engineering, University of Connecticut
>> Homepage: https://sites.google.com/site/amirherzberg/home
>> `Applied Introduction to Cryptography' textbook and lectures:
>> https://sites.google.com/site/amirherzberg/cybersecurity
>>
>>
>>
>>
>> On Mon, Nov 20, 2023 at 5:30 AM Lancheng Qin 
>> wrote:
>>
>>> Hi Amir,
>>>
>>>
>>>
>>> I really enjoy reading this paper, and I’m interested in your design of
>>> preventing attribute manipulations and route leaks.
>>>
>>>
>>>
>>> I think BGP-iSec is useful under a Global Attacker. But I have some
>>> concerns about using ProConIP-list under a Full Attacker (in Sec. III-B).
>>> Using ProConIP-list requires the origin AS clearly knows its provider cone,
>>> which is challenging in practice. Although we can use CAIDA topology to
>>> infer the provider cone of an AS, some provider-customer relationships may
>>> not be discovered by CAIDA topology or other existing AS relationship
>>> inference algorithms. If the ProConIP-list is not accurate or complete
>>> (i.e., covering all BGP-iSec-adopting ASes in the provider cone), it may
>>> cause legitimate BGP announcements to be dropped. Compared to publishing
>>> the whole provider cone, ASPA requires an AS to publish its provider ASes,
>>> which is easier and more feasible. Can we use BGP-iSec and ASPA together? 
>>> Would
>>> that be more beneficial?
>>>
>>>
>>>
>>> BTW, I will also present my new work on routing security in NDSS’2024.
>>> Looking forward to discussing more with you in San Diego:)
>>>
>>>
>>>
>>> Best,
>>>
>>> Lancheng Qin
>>>
>>>
>>>
>>>
>>>
>>> -原始邮件-
>>> *发件人:* "Amir Herzberg" 
>>> *发送时间:* 2023-11-11 07:02:48 (星期六)
>>> *收件人:* N

Re: Help with Frontier circuits AS5650

[TJ Trout]

Irr and rpki are both in order?

On Mon, Nov 20, 2023, 9:56 AM Dennis Burgess 
wrote:

> I have two frontier circuits that are not working correctly with BGP,
> prefixes that are announced are not showing in the global table etc.  Any
> frontier people can tell me where I can call to find someone that can
> assist.  End users are currently down ☹been calling numbers for the
> past hour, no one is picking up.
>
>
>
> *[image: LTI-Full_175px]*
>
> *Dennis Burgess*
>
>
> * Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless
> Engineer, Traffic Control Engineer, Inter-Networking Engineer, Security
> Engineer, Enterprise Wireless Engineer*
>
> *Hurricane Electric: **IPv6 Sage Level*
>
> *Cambium: **ePMP*
>
>
>
> Author of "Learn RouterOS- Second Edition”
>
> *Link Technologies, Inc* -- Mikrotik & WISP Support Services
>
> *Office*: 314-735-0270  Website: http://www.linktechs.net
>
> Create your own Tickets via https://hd.linktechs.net
>
> Create Wireless Coverage’s with www.towercoverage.com
>
> Need MikroTik Cloud Management: https://cloud.linktechs.net
>
> Remote Winbox Service: http://rwb.linktechs.net
>
>
>

Re: ipv6 address management - documentation

[owen--- via NANOG]

> On Nov 16, 2023, at 21:57, Ryan Hamel  wrote:
> 
> Christopher,
> 
> A residential customer would be getting their /56 from the providers pool via 
> RA or DHCPv6. With a /32 aggregate, it can handle 1.6 million /56 
> delegations, which can cover a few regions. It all depends on the planning 
> going into splitting up the aggregate.

Or, if the provider isn’t stingy a /48 from the providers /≤32 (providers can 
get as many /48s as they need to support whatever number of customers receiving 
them, at least in the ARIN region).

> A rule of thumb I go by in the datacenter is, a /48 per customer per site, 
> and further splitting it into /64s per VLAN, all of which can be plugged into 
> a spreadsheet formula to produce a valid complete subnet.
> 
> Either way, keeping track of IPAM via spreadsheet is a recipe for disaster. 
> NetBox and Nautobot are my choices, and is worth deploying on a server or 
> VPS, even for home labs.

On this, we agree.

It’s just not what spreadsheets do.

Owen

> 
> Ryan
> 
> From: NANOG  on behalf of 
> Christopher Hawker 
> Sent: Thursday, November 16, 2023 3:52:59 PM
> To: Aaron Gould ; Owen DeLong 
> Cc: nanog@nanog.org 
> Subject: Re: ipv6 address management - documentation
> 
> Caution: This is an external email and may be malicious. Please take care 
> when clicking links or opening attachments.
> 
> One of the first things that comes to mind, is that if you were to breakout a 
> /64 v6 subnet (a standard-issue subnet to a residential customer) in an Excel 
> spreadsheet, the number of columns you would need is 14 digits long. You 
> could breakout the equivalent of a /12 v4 in just one column. Understandably 
> in the real world no one (in their right mind) would do this, this is just 
> for comparison.
> 
> Regards,
> Christopher H.
> From: NANOG  on behalf of Owen 
> DeLong via NANOG 
> Sent: Friday, November 17, 2023 10:39 AM
> To: Aaron Gould 
> Cc: nanog@nanog.org 
> Subject: Re: ipv6 address management - documentation
>  
> Spreadsheets are terrible for IPAM regardless of address length, but I am 
> curious to know why you think IPv6 would be particularly worse than IPv4 in 
> such a scenario?
> 
> Owen
> 
> 
> > On Nov 16, 2023, at 10:02, Aaron Gould  wrote:
> > 
> > For years I've used an MS Excel spreadsheet to manage my IPv4 addresses.  
> > IPv6 is going to be maddening to manage in a spreadsheet.  What does 
> > everyone use for their IPv6 address prefix management and documentation?  
> > Are there open source tools/apps for this?
> > 
> > -- 
> > -Aaron
> 
> 

Re: Advantages and disadvantages of legacy assets

[owen--- via NANOG]

The only advantage is not being subject to an RIR contract and not paying 
annual fees. Especially with the fee structure games ARIN has been playing over 
the last decade or so.

I made the mistake of bringing my legacy resources under ARIN LRSA contract 
once upon a time. I ended up transferring them to RIPE Non-Contract in order to 
get out from under that arrangement.

While you can’t get RPKI without paying annual fees, you can get IRR services, 
just not from ARIN.

You can use altdb as an IRR for free with legacy space without any issues at 
all.

It’s unlikely that lack of RPKI will be a significant drawback for the 
foreseeable future.

Worst case, if need arises, transfer your space to RIPE and make arrangements 
with a RIPE LIR to “sponsor” your prefixes. This is usually around 70+EU per 
year to the sponsoring LIR. Prices vary greatly, so be prepared to negotiate.

Owen


> On Nov 20, 2023, at 10:59, Eric Dugas via NANOG  wrote:
> 
> Greetings!
> 
> Let's say you inherit legacy assets (ASN & IPv4 netblock), what are the first 
> advantages that come to mind (beside not having to pay annual fees).
> 
> Any disadvantages? The ones I can think of is the lack of RIR routing 
> security services (in the ARIN region at least). No IRR, no RPKI at all.
> 
> Eric

Re: Advantages and disadvantages of legacy assets

[Lukas Tribus]

On Mon, 20 Nov 2023 at 20:08, Rubens Kuhl  wrote:
>
> You can get IRR from RADB or AltDB.

Which is not going to be useful forever ... see [1]:

> Please note that 'route' and 'route6' objects created after 2023-Aug-15
> in non-authoritative registries like RADB, NTTCOM, ALTDB won't be
> processed.




[1] https://lg.as6453.net/doc/cust-routing-policy.html

Re: Advantages and disadvantages of legacy assets

[Rubens Kuhl]

You can get IRR from RADB or AltDB.

Rubens

Em seg., 20 de nov. de 2023, 16:00, Eric Dugas via NANOG 
escreveu:

> Greetings!
>
> Let's say you inherit legacy assets (ASN & IPv4 netblock), what are the
> first advantages that come to mind (beside not having to pay annual fees).
>
> Any disadvantages? The ones I can think of is the lack of RIR routing
> security services (in the ARIN region at least). No IRR, no RPKI at all.
>
> Eric
>

Advantages and disadvantages of legacy assets

[Eric Dugas via NANOG]

Greetings!

Let's say you inherit legacy assets (ASN & IPv4 netblock), what are the
first advantages that come to mind (beside not having to pay annual fees).

Any disadvantages? The ones I can think of is the lack of RIR routing
security services (in the ARIN region at least). No IRR, no RPKI at all.

Eric

Re: Outside plant - prewire customer demarc preference

[Jay R. Ashworth]

- Original Message -
> From: "Sean Donelan" 

> Around here, the local carrier seems to have stopped FTTH deployment.
> Instead, the carrier is convincing home builders not to spend money on
> demarc pre-wire.  Wireless Home 5G service is all customers' need.
> 
> Of course, the lack of demarc planning makes things more expensive for
> any post-construction competitor.  And don't get me started about the lack
> of information of what's available in the utility easments. The builders
> don't know, and the service providers won't say. The FCC broadband maps
> are a lot of hand-waving by service providers.

Well, that's not going to end well.

Sadly, the circumstance in which we'll find out will be if SHTF, and after
that failure, it won't matter much.

Cheers,
-- jra

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: ipv6 address management - documentation

[Justin Krejci]

I give +1 for phpipam



-Original Message-
From: Justin Wilson (Lists) 
mailto:%22justin%20wilson%20%28lists%29%22%20%3cli...@mtin.net%3e>>
To: NANOG mailto:nanog%20%3cna...@nanog.org%3e>>
Subject: Re: ipv6 address management - documentation
Date: Sun, 19 Nov 2023 23:38:28 -0500

Netbox or PHPipam. Phpipam allows you to break down subnets easier IMHo.


Justin Wilson
j...@j2sw.com

—
https://j2sw.com (AS399332)
https://blog.j2sw.com - Podcast and Blog

On Nov 16, 2023, at 1:09 PM, Jason Biel  wrote:

My recommendation:

https://github.com/netbox-community


On Thu, Nov 16, 2023 at 12:04 PM Aaron Gould 
mailto:aar...@gvtc.com>> wrote:
For years I've used an MS Excel spreadsheet to manage my IPv4
addresses.  IPv6 is going to be maddening to manage in a spreadsheet.
What does everyone use for their IPv6 address prefix management and
documentation?  Are there open source tools/apps for this?

Re: Help with Frontier circuits AS5650

[Jeff Richmond]

Dennis, let me see if I can get someone to reach out to you to get this sorted 
out. Can you PM me the circuit IDs and ASN/Prefix info please?

Thanks,
-Jeff

> On Nov 20, 2023, at 9:53 AM, Dennis Burgess  wrote:
> 
> I have two frontier circuits that are not working correctly with BGP, 
> prefixes that are announced are not showing in the global table etc.  Any 
> frontier people can tell me where I can call to find someone that can assist. 
>  End users are currently down ☹been calling numbers for the past hour, no 
> one is picking up.
>  
> 
> Dennis Burgess
> 
> Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, 
> Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, 
> Enterprise Wireless Engineer
> Hurricane Electric: IPv6 Sage Level
> Cambium: ePMP
>  
> Author of "Learn RouterOS- Second Edition”
> Link Technologies, Inc -- Mikrotik & WISP Support Services
> Office: 314-735-0270  Website: http://www.linktechs.net 
> 
> Create your own Tickets via https://hd.linktechs.net 
> 
> Create Wireless Coverage’s with www.towercoverage.com 
> 
> Need MikroTik Cloud Management: https://cloud.linktechs.net 
> 
> Remote Winbox Service: http://rwb.linktechs.net 

Help with Frontier circuits AS5650

[Dennis Burgess]

I have two frontier circuits that are not working correctly with BGP, prefixes 
that are announced are not showing in the global table etc.  Any frontier 
people can tell me where I can call to find someone that can assist.  End users 
are currently down ☹been calling numbers for the past hour, no one is 
picking up.

[LTI-Full_175px]
Dennis Burgess

Mikrotik : Trainer, Network Associate, Routing Engineer, Wireless Engineer, 
Traffic Control Engineer, Inter-Networking Engineer, Security Engineer, 
Enterprise Wireless Engineer
Hurricane Electric: IPv6 Sage Level
Cambium: ePMP

Author of "Learn RouterOS- Second Edition”
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270  Website: 
http://www.linktechs.net
Create your own Tickets via https://hd.linktechs.net
Create Wireless Coverage’s with www.towercoverage.com
Need MikroTik Cloud Management: 
https://cloud.linktechs.net
Remote Winbox Service: http://rwb.linktechs.net

Re: ipv6 address management - documentation

[Justin Wilson (Lists)]

Netbox or PHPipam. Phpipam allows you to break down subnets easier IMHo.


Justin Wilson
j...@j2sw.com

—
https://j2sw.com (AS399332)
https://blog.j2sw.com - Podcast and Blog

> On Nov 16, 2023, at 1:09 PM, Jason Biel  wrote:
> 
> My recommendation:
> 
> https://github.com/netbox-community
> 
> 
> On Thu, Nov 16, 2023 at 12:04 PM Aaron Gould  > wrote:
>> For years I've used an MS Excel spreadsheet to manage my IPv4 
>> addresses.  IPv6 is going to be maddening to manage in a spreadsheet.  
>> What does everyone use for their IPv6 address prefix management and 
>> documentation?  Are there open source tools/apps for this?
>> 
>> -- 
>> -Aaron
>> 
> 
> 
> --
> Jason

Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks

[Tom Beecher]

Amir-

I have to take some issue with one comment you made in response to Job.

BGP-iSec, at this point, is just an academic study studying some new ideas
> and evaluating their impact in specific configurations, under specific
> assumptions etc.; hopefully, this may provide some help to the community in
> improving BGP security.
>

When reviewing the paper , it feels as if BGP-iSec is being presented as a
working solution, not just ideas and theoretical analysis. Care should be
taken not to oversell the status of a thing; that just leads to confusion
and issues later.

Also, as an aside, when most network engineers read statements that
something is "relatively easy to implement", large red lights start going
off in our brains; If we had $1 for every time we heard that and it turned
out to be false, we'd all pretty much be retired. :)








On Mon, Nov 20, 2023 at 10:45 AM Amir Herzberg  wrote:

> Lancheng, thanks for your comment.
>
> About ProConi (and ASPA): so, we're aware it's more challenging than ASPA
> and have evaluated the effort required - it actually doesn't seem too bad,
> although that doesn't mean that it'll be cost effective to use it. But as
> I've mentioned in an earlier email to this list, Joel Halpern (cc:ed) has
> alerted us to an even larger problem with ProConi; the proconi list of a
> given AS may become incorrect due to certain changes in AS relationships,
> leading to possible false-positives for possibly significant time. This is
> obviously very problematic and we are editing this part of the paper to
> reflect this risk. Probably, this mechanism should not be deployed;
> luckily, we obtained good results also with the other defenses against
> leakage in the paper, for the practical case of non-eavesdropping
> adversary. In any case we see the work as the opening point, or another
> step, toward more effective defenses against path manipulations and
> intentional route leaks. More work should be done.
>
> We look forward to meeting you in NDSS; I haven't yet seen list of
> accepted papers, and it'll be great if you can share your paper. But if
> not, then we'll see it in the conference :)
>
> best, Amir
> --
> Amir Herzberg
>
> Comcast professor of Security Innovations, Computer Science and
> Engineering, University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home
> `Applied Introduction to Cryptography' textbook and lectures:
> https://sites.google.com/site/amirherzberg/cybersecurity
>
>
>
>
> On Mon, Nov 20, 2023 at 5:30 AM Lancheng Qin 
> wrote:
>
>> Hi Amir,
>>
>>
>>
>> I really enjoy reading this paper, and I’m interested in your design of
>> preventing attribute manipulations and route leaks.
>>
>>
>>
>> I think BGP-iSec is useful under a Global Attacker. But I have some
>> concerns about using ProConIP-list under a Full Attacker (in Sec. III-B).
>> Using ProConIP-list requires the origin AS clearly knows its provider cone,
>> which is challenging in practice. Although we can use CAIDA topology to
>> infer the provider cone of an AS, some provider-customer relationships may
>> not be discovered by CAIDA topology or other existing AS relationship
>> inference algorithms. If the ProConIP-list is not accurate or complete
>> (i.e., covering all BGP-iSec-adopting ASes in the provider cone), it may
>> cause legitimate BGP announcements to be dropped. Compared to publishing
>> the whole provider cone, ASPA requires an AS to publish its provider ASes,
>> which is easier and more feasible. Can we use BGP-iSec and ASPA together? 
>> Would
>> that be more beneficial?
>>
>>
>>
>> BTW, I will also present my new work on routing security in NDSS’2024.
>> Looking forward to discussing more with you in San Diego:)
>>
>>
>>
>> Best,
>>
>> Lancheng Qin
>>
>>
>>
>>
>>
>> -原始邮件-
>> *发件人:* "Amir Herzberg" 
>> *发送时间:* 2023-11-11 07:02:48 (星期六)
>> *收件人:* NANOG 
>> *主题:* BGP-iSec: Improved Security of Internet Routing Against Post-ROV
>> Attacks
>>
>> Hi NANOGers,
>>
>>
>> We will present our new work, titled: `BGP-iSec: Improved Security of
>> Internet Routing Against Post-ROV Attacks', in NDSS'24.
>>
>>
>> If you're interested in security of Internet routing (BGP), and want a
>> copy, see URL below, drop me a message/email - or see us in the conference
>> - or just read the final version.
>>
>>
>> Available from:
>> https://www.researchgate.net/publication/375553362_BGP-iSec_Improved_Security_of_Internet_Routing_Against_Post-ROV_Attacks
>> --
>> Amir Herzberg
>>
>> Comcast professor of Security Innovations, Computer Science and
>> Engineering, University of Connecticut
>> Homepage: https://sites.google.com/site/amirherzberg/home
>> `Applied Introduction to Cryptography' textbook and lectures:
>> https://sites.google.com/site/amirherzberg/cybersecurity
>>
>>
>>

Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks

[Amir Herzberg]

Lancheng, thanks for your comment.

About ProConi (and ASPA): so, we're aware it's more challenging than ASPA
and have evaluated the effort required - it actually doesn't seem too bad,
although that doesn't mean that it'll be cost effective to use it. But as
I've mentioned in an earlier email to this list, Joel Halpern (cc:ed) has
alerted us to an even larger problem with ProConi; the proconi list of a
given AS may become incorrect due to certain changes in AS relationships,
leading to possible false-positives for possibly significant time. This is
obviously very problematic and we are editing this part of the paper to
reflect this risk. Probably, this mechanism should not be deployed;
luckily, we obtained good results also with the other defenses against
leakage in the paper, for the practical case of non-eavesdropping
adversary. In any case we see the work as the opening point, or another
step, toward more effective defenses against path manipulations and
intentional route leaks. More work should be done.

We look forward to meeting you in NDSS; I haven't yet seen list of accepted
papers, and it'll be great if you can share your paper. But if not, then
we'll see it in the conference :)

best, Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
https://sites.google.com/site/amirherzberg/cybersecurity




On Mon, Nov 20, 2023 at 5:30 AM Lancheng Qin 
wrote:

> Hi Amir,
>
>
>
> I really enjoy reading this paper, and I’m interested in your design of
> preventing attribute manipulations and route leaks.
>
>
>
> I think BGP-iSec is useful under a Global Attacker. But I have some
> concerns about using ProConIP-list under a Full Attacker (in Sec. III-B).
> Using ProConIP-list requires the origin AS clearly knows its provider cone,
> which is challenging in practice. Although we can use CAIDA topology to
> infer the provider cone of an AS, some provider-customer relationships may
> not be discovered by CAIDA topology or other existing AS relationship
> inference algorithms. If the ProConIP-list is not accurate or complete
> (i.e., covering all BGP-iSec-adopting ASes in the provider cone), it may
> cause legitimate BGP announcements to be dropped. Compared to publishing
> the whole provider cone, ASPA requires an AS to publish its provider ASes,
> which is easier and more feasible. Can we use BGP-iSec and ASPA together? 
> Would
> that be more beneficial?
>
>
>
> BTW, I will also present my new work on routing security in NDSS’2024.
> Looking forward to discussing more with you in San Diego:)
>
>
>
> Best,
>
> Lancheng Qin
>
>
>
>
>
> -原始邮件-
> *发件人:* "Amir Herzberg" 
> *发送时间:* 2023-11-11 07:02:48 (星期六)
> *收件人:* NANOG 
> *主题:* BGP-iSec: Improved Security of Internet Routing Against Post-ROV
> Attacks
>
> Hi NANOGers,
>
>
> We will present our new work, titled: `BGP-iSec: Improved Security of
> Internet Routing Against Post-ROV Attacks', in NDSS'24.
>
>
> If you're interested in security of Internet routing (BGP), and want a
> copy, see URL below, drop me a message/email - or see us in the conference
> - or just read the final version.
>
>
> Available from:
> https://www.researchgate.net/publication/375553362_BGP-iSec_Improved_Security_of_Internet_Routing_Against_Post-ROV_Attacks
> --
> Amir Herzberg
>
> Comcast professor of Security Innovations, Computer Science and
> Engineering, University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home
> `Applied Introduction to Cryptography' textbook and lectures:
> https://sites.google.com/site/amirherzberg/cybersecurity
>
>
>

CBS / Paramount+ geoloctaion contact

[George Toma]

We are getting Unauthorized location response headers from Irtdeto on
Paramount Plus content when accessed from some of our subnets (several
subnets within a particular /21).
{"code":130301,"message":"Content is not available in this location."}

Other subnets (different /22s) of ours work fine.

Irdeto says the geolocation acceptance is done by the customer, in this
case Paramount Plus / CBS.

Does anybody have a contact at CBS/Paramount+ with whom I could escalate
these issues?

Thank you.

George Toma
VISNETWORK SRL

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN79 Community Forum

[Jacques Latour via NANOG]

Call for Participation – ICANN DNSSEC and Security Workshop for ICANN79 
Community Forum



In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN79 Community Forum 
being held as a hybrid meeting from 02-07 March 2024 San Juan, Puerto Rico in 
the Atlantic Standard Time - AST (UTC-4). This workshop date will be determined 
once ICANN creates a block schedule for us to follow; then we will be able to 
request a day and time. The DNSSEC and Security Workshop has been a part of 
ICANN meetings for several years and has provided a forum for both experienced 
and new people to meet, present and discuss current and future DNSSEC 
deployments.  For reference, the most recent session was held at the ICANN78 
The Annual General Meeting on Wednesday, 25 October 2023. The presentations and 
transcripts are available at: https://icann78.sched.com/.


The DNSSEC Workshop Program Committee is developing a program for the

upcoming meeting.  Proposals will be considered for the following topic areas 
and included if space permits.  In addition, we welcome suggestions for 
additional topics either for inclusion in the ICANN78 workshop, or for 
consideration for future workshops.



1.  Global DNSSEC Activities Panel

For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.



2.  DNSSEC Best Practice

Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?

  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?



Activities and issues related to DNSSEC in the DNS Root Zone are also desired.



3. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?



4. Security Panel

The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.



We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:


  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security – DNS, DNSSEC, DoH
  *   EMAIL & DNS related security – DMARC, DKIM, TLSA, etc…



If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org 
by COB Friday, 19 January 2024.



Thank you,

Kim and Kathy

On behalf of the DNSSEC Workshop Program Committee:

Steve Crocker, Edgemoor Research Institute

Mark Elkins, DNS/ZARC

Jacques Latour, .CA

Russ Mundy, Tislabs

Yoshiro Yoneya

Dan York, Internet Society







CLASSIFICATION:PUBLIC

Re: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks

[Lancheng Qin]

Hi Amir,

 

I really enjoy reading this paper, and I’m interested in your design of 
preventing attribute manipulations and route leaks.

 

I think BGP-iSec is useful under a Global Attacker. But I have some concerns 
about using ProConIP-list under a Full Attacker (in Sec. III-B). Using 
ProConIP-list requires the origin AS clearly knows its provider cone, which is 
challenging in practice. Although we can use CAIDA topology to infer the 
provider cone of an AS, some provider-customer relationships may not be 
discovered by CAIDA topology or other existing AS relationship inference 
algorithms. If the ProConIP-list is not accurate or complete (i.e., covering 
all BGP-iSec-adopting ASes in the provider cone), it may cause legitimate BGP 
announcements to be dropped. Compared to publishing the whole provider cone, 
ASPA requires an AS to publish its provider ASes, which is easier and more 
feasible. Can we use BGP-iSec and ASPA together? Would that be more beneficial?

 

BTW, I will also present my new work on routing security in NDSS’2024. Looking 
forward to discussing more with you in San Diego:)

 

Best,

Lancheng Qin








-原始邮件-
发件人:"Amir Herzberg" 
发送时间:2023-11-11 07:02:48 (星期六)
收件人: NANOG 
主题: BGP-iSec: Improved Security of Internet Routing Against Post-ROV Attacks



Hi NANOGers,




We will present our new work, titled: `BGP-iSec: Improved Security of Internet 
Routing Against Post-ROV Attacks', in NDSS'24.




If you're interested in security of Internet routing (BGP), and want a copy, 
see URL below, drop me a message/email - or see us in the conference - or just 
read the final version.




Available from: 
https://www.researchgate.net/publication/375553362_BGP-iSec_Improved_Security_of_Internet_Routing_Against_Post-ROV_Attacks

--

Amir Herzberg



Comcast professor of Security Innovations, Computer Science and Engineering, 
University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and 
lectures:https://sites.google.com/site/amirherzberg/cybersecurity

Re: Outside plant - prewire customer demarc preference

[Sean Donelan]

Around here, the local carrier seems to have stopped FTTH deployment. 
Instead, the carrier is convincing home builders not to spend money on 
demarc pre-wire.  Wireless Home 5G service is all customers' need.


Of course, the lack of demarc planning makes things more expensive for
any post-construction competitor.  And don't get me started about the lack 
of information of what's available in the utility easments. The builders 
don't know, and the service providers won't say. The FCC broadband maps 
are a lot of hand-waving by service providers.