Re: [anti-abuse-wg] postal address in IRT objects

2022-07-22 Thread Alexander Talos-Zens
Hej,


> usefulness (or not) of a mandatory  postal address in the IRT object.

If I can't reach someone by electronic media, I doubt I'd get better
response to snail mail. Furthermore, purely virtual teams might not
have a true physical location at all. 

Cheers,

Alexander Talos-Zens

-- 
Alexander Talos-Zens
IT-Security - ACOnet-CERT
Zentraler Informatikdienst
https://zid.univie.ac.at


Universität Wien
Universitätsstraße 7
1010 Wien
T +43-1-4277-14351
a...@univie.ac.at
GPG-Key-Id: 0x757A494B


-- 

To unsubscribe from this mailing list, get a password reminder, or change your 
subscription options, please visit: 
https://lists.ripe.net/mailman/listinfo/anti-abuse-wg


Re: [anti-abuse-wg] AS16019, vodafone.cz == idiots

2020-12-14 Thread Alexander Talos-Zens
Hej,

lör 2020-12-12 klockan 02:36 -0800 skrev Ronald F. Guilmette:

> how inept and
> dysfunctional even so-called "first world" systems are at dealing
> with anything that is even just a little bit out of the ordinary.

You're referring to your wording in the subject, aren't you?

Cheers,

Alexander

-- 
Alexander Talos-Zens
IT-Security - ACOnet-CERT
Zentraler Informatikdienst
http://zid.univie.ac.at


Universität Wien
Universitätsstraße 7
1010 Wien
T +43-1-4277-14351
a...@univie.ac.at
GPG-Key-Id: 0x757A494B




Re: [anti-abuse-wg] Spamming LIR accounts

2020-05-07 Thread Alexander Talos-Zens
Hej,

Den 2020-05-07 kl. 12:52, skrev Töma Gavrichenkov:

> and thus one candidate has just obtained unfair advantage,
> for which there should be consequences).

I doubt this actually qualifies as *advantage*. I'm optimistic that the
consequences will come with the election results.

I'm afraid we're feeding the troll here.

Cheers,

Alexander



Re: [anti-abuse-wg] 2019-03 Review Phase (Resource Hijacking is a RIPE Policy Violation)

2019-09-09 Thread Alexander Talos-Zens
Hej,

this is my first post in this list - my perspective is taht of a
security guy with little knowledge about BGP or the inner workings of
RIPE, but very interested in everything that helps definding against the
bad guys.

Den 2019-09-05 kl. 15:23, skrev Marco Schmidt:

> The goal of this proposal is to define that BGP hijacking is not
> accepted as normal practice within the RIPE NCC service region.

Firstly, thanks everyone involved for the effort in setting up this
policy proposal. I like many points, e.g. that it makes clear that
accidental events shall not be reprimanded. Others might deserve being
rephrased, e.g. CSIRTS being entitled to file reports.

On the other hand, I had a hard time trying to determine the positive
impact of the proposed policy.

On the formal side, to define that hijacking is a violation of policy
without specifying which policy is violated gives me a mental blue
screen. As far as I know, please correct me if I'm wrong, there is no
policy in RIPE that proscribes hijacking, and neither would 2019-03 do that.

This makes sense to me, as (again, correct me if I'm wrong) RIPE isn't
involved in routing operations - but that's where hijacking attacks take
place.

Should RIPE kick out the evil LIRs? Maybe, but the proposed policy
doesn't do that. The opposite holds true: "RIPE-716) may apply." and
"This policy does not endorse the initiation of an LIR closure procedure
on the basis of a single policy violation." No mention what happens
after multiple (how many? depending on LIR size? ...) violations.

I failed to find any way how implementing this proposal would improve
security. I've also tried to save the proposal's impetus by coming up
with realistic and effective suggestions - but failed as well.

For now, my conclusion is that this isn't the way to go.

Cheers,

Alexander

-- 
Alexander Talos-Zens
IT-Security - ACOnet-CERT
Zentraler Informatikdienst
http://zid.univie.ac.at

Universität Wien
Universitätsstraße 7
1010 Wien
T +43-1-4277-14351
a...@univie.ac.at
GPG-Key-Id: 0x757A494B