Subject: Comments on rps-auth-02 draft

From: David Woodgate <[email-masked]>
Date: Thu, 18 Mar 1999 01:38:30 +1100

Curtis,

Here are a few comments on the auth draft:

1.	Trust Model

	A.	I believe that (intentionally) the document does not deal
		with any issues concerning the security of queries to the
		database. This may be obvious, but it should probably be
		stated explicitly somewhere anyway.

	B.	My understanding of the processes surrounding the submission
		of a new object to a registry is that it only relies
		on checks from the immediate (potential) parent objects.
		However, I don't believe that at any stage is the authentication
		or the integrity of those parent objects rechecked. In other
		words, once the data is in the repository, it is assumed
		to be valid - there are no subsequent rechecks of validity.

		(Please correct me if I'm wrong about this.)

		This is a fine assumption to make, but it probably should
		be stated explicitly - at least in a comment in the security
		section, and possibly even in a separate, small (one sentence)
		section around the same area in the document, as the
		"Implicit Policy Assumptions" section.

2.	mnt-routes vs. mnt-lower

	After our discussion, I understand some of the historical and
	legacy issues involved in these attributes. Nevertheless, I'm
	still concerned that there is significant potential for confusion
	about which gets used where and why.

	Would there be a possibility of either:
	(a)	Deprecating the use of one, and prefer the other;
	(b)	Merging the two attributes into one?

	With respect to the definition of the mnt-routes attribute
	in section 9.1, it might be worth reusing the bulk of the last
	paragraph in section 8.1 to replace the second and third sentences
	of the section 9.1 definition, as I think the 8.1 paragraph
	was clearer about the functions of mnt-routes.

3.	Section 8.8 "Query Processing"

	Since the document doesn't really deal with queries, is there
	a real need for this section? Or could it be deleted? (Not
	that I'm particularly worried by it.)

4.	Examples

	I think some examples of object/attribute addition/deletion/modification
	could be useful in making some concepts unambiguous.

5.	Editorial
	
	A.	Typo - section 9.1, definition of mnt-routes, second-last
		sentence - "the mnt-lower or mnt-by mnt-by attribute"
		Too many mnt-by's.

	B.	Section 8.5, second-last paragraph

  "Similarly a no-reclaim attribute cannot be deleted unless there are
  no overlapped objects for which the submitter is not listed in the
  maintainer pointed to be the mnt-by of the overlapped object."

		I would suggest that it can be difficult to think through
		all the negatives. May I suggest something like the
		following instead?

  "Similarly, a submitter may delete a no-reclaim attribute from
  an object only when that submitter is the only maintainer listed
  in the mnt-by attributes of any overlapped objects. If the mnt-by
  attributes of any overlapped objects point to maintainers other than
  the submitter, then it is not permitted to delete the no-reclaim
  attribute."

								davidw

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Mar 1999 12:06:00 -0500

In message <[email-masked]>, David Woodgate 
> 		stated explicitly somewhere anyway.

It doesn't actually deal with queries.  rps-dist explicitly states
that queries are out of scope.  I can add that security of queries and
encapsulation of queries is out of scope.

[aside: My personal suggestion is to add a flag to the whois query
that requests a PGP signature on the query response.  rps-dist already
has a reference to a cert object to provide the public key.]

> 		(Please correct me if I'm wrong about this.)

The checks are on the original submission no matter how far down the
flooding exchange it is.  The authentication on the submitted
transaction is checked and the authorization of that change is
checked.  The signatures of the registries count for nothing if you
don't want to trust your flooding peers.

I think we're clear on that.

There is no need to check beyond the immediate parent objects.  If the
database ran rps-auth from day one, they could not get into the
database without being properly authorized.  The rps-dist draft
addresses the issue of using old data with the integrity attribute.
An object can't get into the database as ``authorized'' if the parents
were not in the database as ``authorized''.  This means that
everything now in the database from the top down needs to be
resubmitted or it will be forever branded as possibly bogus.

> 		"Implicit Policy Assumptions" section.

I can add something like the paragraph above but then we have a
dependency on rps-dist which we can't cite unless we advance the two
documents together.  Because of this I'd rather just leave this out.
Is that OK with you?

> 	was clearer about the functions of mnt-routes.

I will assume that the definition discussed at the meeting stands
unless RIPE who are now using mnt-lower and mnt-routes agrees to some
sort of merge.  It is hard to do this because mnt-lower has different
meaning in an aut-num than mnt-routes with no prefix (it allows
addition of route-sets and as-sets with hierarchical names).

> 	that I'm particularly worried by it.)

Didn't you ask for an explicit statement on the security of queries a
few lines above?  Seems like a good place for a conspicuous "this is
out of scope" statement regarding query encapsulation and security.

I will also mention this in the security section.

The reason this section exists is it defines where a properly
authorized object would be found.  I suppose in the absense of a
properly authorized object the possible bogons in other repositories
could be reported.  This might deserve mention.

> 	could be useful in making some concepts unambiguous.

This would be a significant addition in size only.  There is a
potential for mistakes which could delay the draft (particularly at
the rate this WG reviews things) or if rushed through on the
assumption that silence is consent the potential to go forward with
examples that are simply wrong.  I'll try to put together a limited
number of very simple examples and hope people in the know on this
list read them before or during last call.

>   the submitter, then it is not permitted to delete the no-reclaim

Thanks for the comments.  I'll be editing for the last call soon,
maybe later today depending on mail volume and interrupt levels.

Curtis