From: Curtis Villamizar <[email-masked]>
Date: Thu, 11 Feb 1999 11:53:34 -0500

Mark Prior ([email-masked]) on January 25:
>      rps-auth solves "some other maintainer can't come along and recreate
>      the original record" problem.
>
> I am not convinced that it will. It is fine in theory but practice
> will be an entirely different matter.
>
> In Australia there are 4 main IAPs (Connect, Optus, OzEmail and
> Telstra). We each register our customers routes in the IRR (Telstra
> uses CW and registers all customers under their AS while the rest of
> us register in RADB). Just about none of the smaller ISPs appear to
> know/care about the IRR and leave it up to the big 4 to register their
> routes (it's pretty rare that an Australian ISP doesn't have a link to
> at least one of the big 4). Internet charging being what it is the
> smaller ISPs move around, don't send all their routes to all their
> upstreams etc. If a customer connects to Connect (say) we will
> register their route in RADB (under their AS). If they then get
> another link to Optus then they will try to register their route but
> will fail since we have already hijacked it (we get a nice message
> from RADB telling us that the customer now has a link to Optus :-) Now
> should the customer sometime later cancel their link to Connect we
> will (currently) withdraw the route. There is no mechansim to warn
> Optus that we have done this so the first they know about it is when
> the customer complains.

Hi Mark,

Late response..  I'm going through mail regarding rps-auth.

This requires no change, just an explanation.

The customer gets their address allocation from a registry somewhere.
Maybe there will be an OZNIC in the future.  With the address
allocation they are strongly encouraged to include a cryptographic
public key of some sort, currently PGP.  I don't know how long
mail-from will be an accepted option.

In your example, the right way to handle this would be for Connect to
send a message briefly explaining what the IRR is about (for those
that haven't heard of it) and ask the customer to sign the route
object that you have already signed and mail it back to you.  If
mail-from was still in use, they could mail it in.  The route object
(not the inet-num) would have a Connect maintainer referenced in a
mnt-by line in addition to the customer's maintainer.

When a second provider comes along, Optus in your example, Optus can
do the same, adding a route object with their AS and the same address.
There is no requirement for one origin AS per route IP prefix.

When the customer disconnects from Connect, then Connect can delete
the route object that contains Connect's AS, but Connect can't delete
or modify the route object that contains Optus AS or the inet-num.

If the maintainer chaining is implemented, in order to get the address
allocation a maintainer is needed.  If the customer's first connection
to the Internet is through Connect, then it is likely that Connect
will provide the maintainer referal.  If the customer is completely
without a clue, then Connect can offer to get the address allocation
and use Connect's maintainer.  In this case if the customer moves from
Connect to Optus, Connect can notify Optus (who presumably being a
major provider has some clue), add Optus to the mnt-by and Optus can
drop Connect from the mnt-by (recall that you can't delete yourself
for protection from your own mistakes).  Somewhere the customer should
be notified but since this example presumes total absence of clue the
customer will have no idea what you are talking about and won't care
as long as connectivity remains up.

I think this is the best we can do implementing a reasonably strong
authorization model in the presence of some parties that have no clue
and don't care.

Curtis

---

From: Mark Prior <[email-masked]>
Date: Fri, 12 Feb 1999 09:51:31 +1030

We have been down the AUNIC registry path and I doubt anyone is going
to be willing to go down there again :-)

Yes but if the customer has an AS their route will be registered with
it as the origin by both Connect and (the attempt made) by Optus
(Telstra don't do this but that's another story :-)

In the case where the customer uses their AS I still think we have a
problem, especially in an automated environment, of disentangling the
mess if the customer leaves the provider who created the route object.

     and use Connect's maintainer.

I think this is unlikely, if the customer wants portable address space
then they have to join APNIC and get it themselves. None of the
providers offer portable address space or a mechanism to get it. Some
customers will have portable address space due to age of the
allocation (ie it's come from InterNIC or the former AUNIC) and not
know about any of this but that's an education problem (I hope).

                                    In this case if the customer moves from

This assumes that Connect knows, customers don't normally tell you who
they are moving to when they cancel.

Well I think this is a problem, if it's not "easy" to use and automate
then it's going to fail.

Mark.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Feb 1999 10:34:53 -0500

> (Telstra don't do this but that's another story :-)

That wasn't your example.

If the customer has their own AS this implies an at least somewhat
clueful customer, at least clueful enough to know that AS numbers
exist and that the Internet doesn't just run RIP.

The customer with their own AS should register their as-block and
aut-num.  If they need help, they might ask you to register and leave
both you and them in the maintainer.  The transition would then be a
matter of changing the maintainer (and Connect and Optus have to
change their routing policy and possibly aggregation when the dual
home and the drop of the original provider occur, but that doesn't
impact the customer's registry objects).

> mess if the customer leaves the provider who created the route object.

Why?  You can always change the mnt-by.

> know about any of this but that's an education problem (I hope).

Are we arguing that there is something to be changed in RPSL or are we
arguing whether the example was politically reasonable.

> they are moving to when they cancel.

This was wrt the inet-num.  Just notify the customer that they know
have responsibility to maintain that object.  If they cancelled and
where announced from your AS, you also delete the route object.  If
they had their own AS, you inform them that they have to maintain that
as well.

> Well I think this is a problem, if it's not "easy" to use and automate

I disagree.  We already have cron jobs that submit some of our objects
when the registry copy differs from the copy we keep locally on CVS.
It is quite easy to have a program PGP sign a file and mail it.

What level of automation of route object submission are you aiming
for?  How does this stand in the way of the automation you have in
mind?  How do you suggest we improve this without abandoning the idea
of having any authorization required to make additions of changes?

Curtis

---

From: Mark Prior <[email-masked]>
Date: Wed, 17 Feb 1999 09:22:51 +1030

Not to put too fine a point on it but you appear to have more faith in
the cluefulness of the customer than I do.

Because it is very rare for a customer to drop connectivity to us
before connecting to someone else. In my experience they connect to
someone else and some time later drop the link to us. I have no idea
what Optus does when they receive the bounces back from RADB saying
that they aren't the maintainer for the route objects they are trying
to register but this was one of the reasons I'm now running my own
registry.

I am arguing that it is dangerous to assume everyone who has an AS
(and/or provider independent address blocks) also has a clue.

Noone touches our registry (aside from me when I install new versions
of the code or fix cockups), it is all driven by our scripts. This is
the level of automation that I want to keep. We generate the
appropriate objects for the particular DB we are operating on, eg
RIPE-181 or RSPL, so I have no problems doing special tasks but I do
have a problem if the customer has to do anything more than tell me
that a particular prefix is now accessible (or no longer accessible)
through them.

I don't have an answer to the problem right now, I'm just signalling
that I think we do have a problem.

Mark.