Subject: Re: [RPSEC] issue: ASPATH

From: Sandy Murphy <[email-masked]>
Date: Wed, 9 Mar 2005 10:47:58 -0500 (EST)

>It is.  But without global distribution of policy information, one
>man's wacko is indistinguishable from a shrew business decision.

A hidden feature of some of the topics, examples, comments that I
made are that policy causes the problem, policy is being violated,
policy is not being communicated, etc.

Policy gets mentioned in the draft, as part of the "Areas to secure":

   o  The originator and the propagators of prefix information may have
      their policy information verified such that the intent of the
      policy with respect to the specific prefix is preserved

and gets mentioned again as a "required to propogate at the same rate":

   o  The distribution of information about connectivity between
      autonomous systems and autonomous system polices, if such
     information is to be distributed within the security system.

But policy does not come in when the requirements are being listed.
So should it?

I do have some reservations about creating a mechanism to distribute
policy - simply because policies now-a-days seems to be so dependent
of the business model.  When (not if) the business model changes,
policy communication mechanisms could get OBE.  Not to mention the
oft-repeated reluctance of ISP's to expose their policies.  I'm
more comfortable with communicating "this is indeed the result of
my internal policy decision" which leaves unsaid what the policy
would be.

I recognize that there is a problem with communicating "and here's
my authorization of what you can do with my data".  That expands
the implicit "here's my route, you can use it for traffic" to
something that is so complicated that it can no longer be implicit.

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Doug Montgomery <[email-masked]>
Date: Wed, 09 Mar 2005 11:48:28 -0500

> my internal policy decision" which leaves unsaid what the policy

*Distributing* enough information so that you could infer from a far
what policy decision another AS would make seems entirely intractable along
numerous dimensions (scale, representation, distribution mechanisms, privacy
concerns, etc).

This would be hard enough if one was only concerned with the decisions an
AS makes up to itself (i.e. the suffix of the PATH from the AS in question
to the source).  If you are concerned about down stream policy (i.e., what
others can do with my announcements), it only seems worse.

If you are only concerned about the former, to some extent, the routes
that a AS propagates is a statement of
the result of its internal policy decision (including local pref).
i.e., I show my neighbors my view of the set of optimal PATHS.
To some extent, as long as you can verify the origin and integrity of the a
given AS's contribution to the PATH, you might infer that at least the
suffix of the PATH is indeed the result of my internal policy decisions.

If you could verify origin and integrity of PATH suffixes, I see no
reason to out of band ask an AS if what your are seeing is in its set
of optimal, viable, feasible, or potential paths.

If you are unable to verify PATH suffixes, or don't trust them for some reason,
then you might want to infer from a far if a given announced PATH suffix is in
an AS's set of optimal, viable, feasible and/or possible paths.

I will note that even if it is query based, allowing me to "probe" any set
either than optimal PATHS, would allow me to discovery information that you
may not want public.  Of course the more volatile information (e.g., optimal
paths) has some temporal/stability concerns if you are verifying it from afar.

> something that is so complicated that it can no longer be implicit.

Yep, verifying PATHS as being consistent with downstream policies is
a whole new can of worms.

As you suggest, we should really think about what aspects of policy
can be protected/verified and at what cost.

dougm