Has PSI been assigned network 1?

Mailman List Mirror (Read Only)
1

telent info.ripe.net to test it out.

RIPE database does not control the actual routing.

I'm not sure the current RADB project has any mention
of real-time updates of gated from the database.

`With dozens of updates we do every day it nearly as good

as useless.

CERN (as an example) picks up my routing updates daily and builds its
new access filter based on mine and others routing updates. I'm not
sure you want realtime updates to the actual routing. In any event,
it is an improvement over the time lag of NACR updates.

It should be secure.

I use a password on all AS updates to AS378.

You call *that* secure? We have way too many people who
need to do changes for our AS-es. Check the contact
list for AS1800.

You can assign as many users as you wish to control specific ASs.
Currently it checks my email address and password. No match -
and the maintainer of the AS gets a warning mail about the attempt
to alter the routing within my AS - and I have gotten warning
e-mails already. Adding in PGP authentication should not be too
hard if it is not done already.

If i can't implement my existing policy, i cannot use RADB, ok?

(Well, we _will_ use it -- to talk to people whose announcements
are loaded with garbadge). We simply cannot use it to talk
to major service providers because policies in place cannot
be represented in RIPE-81.

So speak to the authors and get it improved.

--vadim

Hank

2

From: Hank Nussbacher <HANK@taunivm.tau.ac.il>
Currently it checks my email address and password. No match -
and the maintainer of the AS gets a warning mail about the attempt
to alter the routing within my AS - and I have gotten warning
e-mails already. Adding in PGP authentication should not be too
hard if it is not done already.

We would be much more comfortable with PGP. Currently, passwords are going
in cleartext over Email, not an impressively secure scheme.

Though PGP does preclude automatic submission by maintainers who do not wish
to keep secret keys online. Personally, I will accept the restriction.
Inter-RR exchanges (e.g. RIPE/RADB/MCI/...) may find such restrictions more
of a problem.

I have some tangential questions. Currently, we submit
    o NACRs
    o SWIPs to InterNIC
    o email re routing updates to Sprint
    o 81ish objects to MCI
    o 81ish objects to the RADB
and I am told we will be moving to rwhois.

0 - Why the same data to MCI and RADB? It would seem reasonable to send all
    updates to one registry and have the others fetch what they need.

1 - When can do stop needing NACRs? Monday, i.e. effectively now?

2 - The RADB has a lot of old, now obsolete, data maintained by others. Do
    we have to ask each old maintainer to clean it out, or will it all be
    cleaned up as the changeover settles down?

3 - SWIPs and 81ish objects (and NACRs, but they're going away, yes?) share
    a non-trivial subset. Are there maintainers' tools for generating both
    from a single database? If not, we will surely create errors of
    consistency.

4 - Are there more appropriate fora for weenie questions?

FYI, despite the lack of rigor, Sprint's has seemed (from the bottom of the
pond view) to be the most immediate and reliable over the many moons. ( Of
course, with only 700 customers as compared to, e.g., Karl's 5,000 they have
a much easier time of it. :slight_smile: But the overwhelming problem with all avenues
has been the NACR delay.

3

Hank,

Enduser filtering (CERN) is in principle completely different from what we
(might if not possible else) do:

I am not supposed to filter anything between meetpoints and customers,
because I agree to some people who pay for it to provide Internet access.

I would filter nothing at all (curretnly do filter nothing), which does
not mean that my suport hosts and networks are open.
Filtering comes alo into place when customers want only access between
certain networks,
but in general

NSPs/ISPs are not supposed to filter at all.

Routing is different. We filter routing updates (not access filters) to
accelerate BGP convergence. We filter what we announce to the outside
world (of course not all the trash we get in).

That is not that fast paced changing data since the provider-provider
structure is rather stable.

And we don't need to nacr for each small 2 node attachment either, so I
see no big workload there.

Why must the NACR process be so responsive?

Mike