Subject: Re: The trust model (Re: the problem that needs solving)

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Sep 1998 02:19:11 -0400

In message <[email-masked]>, Harald Tveit Al
vestrand writes:
> 
> Hmmmm.........
> 
> Seems to me we've more or less agreed that we need two statements
> in the language of expressing the difference between "right" and
> "wrong" announcements:
> 
> 1) "I (assigner) believe that the address prefix P can be legally
> announced by AS number (assignee-AS)".
> Let's assign a symbol to it, and call it Assign(P -> AS).

I don't think we can make the assumption that the assigner knows what
AS a prefix will be advertised as.  For example, in the case of small
ARIN assignments, these are generally announced with the AS of the
transit provider that assignee chooses.  The assignee may or may not
have there own AS number and may choose more than one provider or may
switch providers.

> 2) "I (assigner) believe that (assignee-AS) is owned by (assignee-identity)"
> Assign(AS -> ID)
> 
> At the moment, ARIN and the others make a third kind of statement,
> rather than the first kind, which is of the form 
> 
> 3) "I (registry) believe that address prefix P is
> assigned to (assignee-identity)". Assign(Prefix -> ID).

ARIN and others make the mapping AS -> ID and Prefix -> ID only.

> The registry currently doesn't care which of its AS numbers (or someone
> else's AS number) the assignee assigns it to.
> 
> We can get what we want out of it if we assume some sanity on the behalf
> of providers and say that:
> 
> Assign(Prefix -> AS) => Assign(AS -> ID) && Assign(Prefix -> ID)
> 
> (this is formal implication; it says that if the lefthand side is
> true, and the whole equation makes sense, both righthand terms are true.
> It's still valid if the lefthand is false and both righthand terms are true,
> for instance when an ISP chose to allocate the prefix to one of several
> ASes owned by that ISP, and there's NO temporal element in the arrow).

What you have stated is correct.  

Assign(AS -> ID) && Assign(Prefix -> ID) is a neccesary but not a
sufficient condition for Assign(Prefix -> AS).

> Now we're in the "current, unsigned IRR" model; we have statements,
> but we have to trust them more or less implicitly - "take it or leave it".
> In order to get more trust, I think we *have* to introduce signing, noting
> not only what was said, but who said it.
> 
> Let's write "X says Assign(A -> B)" as A.X(A -> B)

Reality is actually a bit more complex than that.  ARIN not only
assigns something but gives the right for subdelegations.  I
understand the notation, but it carries the assumption that if B is an
ID, B can sign for subdelegations or (at least some) changes to A.

So far this fits the model provided in rps-auth quite well.

> We then WANT to believe the BGP assertion "Route 195.124.134/24 via AS12345"
> if and only if we already know (assuming we all trust IANA):
> 
> 1) A.IANA(195/8 -> ARIN)
> 2) A.ARIN(195.124/16 -> MCI)
> 3) A.MCI(195.124.134/24 -> MomAndPopISP)
> 
> 4) A.IANA(AS10000-12999 -> ARIN)
> 5) A.ARIN(AS12345 -> MomAndPopISP)
> 
> OTOH, if 2) said "A.ARIN(195.124/16 -> UUNET), we don't want
> to believe the BGP assertion, unless we also knew an assertion that
> said "A.UUNET(195.124.128/17 -> MCI)".

It would be nice if UUNET could limit what it was turning over to MCI
in this case.  This is where the mnt-routes came in rather than
maintainers.

> This will guard us against misconfigurations of the last BGP hop, which
> I take it is the only level we're trying to aim at now.
> (I think guarding against malicious BGP announcements is a problem
> that requires a rather more complex model, which we're not doing).
> 
> Is this, put as simply as possible, what we want to achieve?

Protecting against anything more than the first BGP hop requires that
you know who is interconnected.  You could make a first order
approximation knowing only the AS adjacencies (existence of peerings).
To truly know if one of your peer AS could be announcing a given
prefix that is multiple AS hops away, you need to know the adjacencies
and the routing policies at those adjacencies.  That would be nice but
cooperation here has been spotty.

> (Note that in this note, I've focused SOLELY on *who* makes the assertion,
> and not said anything about *where* they are stored, or *how* they are
> fetched; I believe that can be relatively flexible, once we decide
> what the trust model we want is.)
> 
>                 Harald A

Thanks for the summary.  Which parties are allowed to make certain
assertions as you describe are the topic of the rps-auth draft
(draft-ietf-rps-auth-01.txt).  You already know this.  I'm pointing it
out for some of the newly active participants on this list.

Curtis

---

From: [email-masked]
Date: Tue, 8 Sep 1998 08:21:58 -0700 (PDT)

> > Harald Tveit Alvestrand writes:

	I think that the assumption "ARIN...gives the right for subdelegations"
is false. The "right" to sub-delegate is inherent in the structure of IP
addresses.  W/O any prior approval from an upstream, I may carve out small
chunks of prefixen and do what I like with them.

--bill

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Sep 1998 14:25:51 -0400

> chunks of prefixen and do what I like with them.

Are we having petty semantics arguments?  Would it be OK if I said,
"if ARIN made the assignment, then ARIN records the 'right' to
sub-delegate that is inherent in the structure of IP addresses such
that modification can be made to the routing registry reflecting this
inherent right"?  It would have seemed overly wordy to me.

Curtis

---

From: [email-masked]
Date: Tue, 8 Sep 1998 11:33:23 -0700 (PDT)

> inherent right"?  It would have seemed overly wordy to me.

	If you are agreeing with me that the assumption, as originally
	worded, is false, then we can proceed w/ new wording.
	
	If I was to propose new wording, it might be something along the
	lines of:

	"If any RIR makes a delegation, this provides the delegate with 
	the opportunity to publish authoritative routing policy for that
	specific delegation. If the delegate makes further sub-delegations 
	from the address space they have responsibility for, they also provide
	the sub-delegates with the same opportunity to publish independent
	routing policy for the specific address space so delegated."

	But that would be my particular take. YMMV.      

-- 
--bill

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 08 Sep 1998 16:50:33 -0400

> 	But that would be my particular take. YMMV.      

It doesn't really matter if we are arguing over the wording of a
sentence in an email message.  So lets just drop it.

If you have a problem with the wording of one of the WG drafts, then
that's another issue.

Curtis