Subject: [sidr] Prefix Origin Validation & AS_SET

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 27 Jun 2011 16:06:22 +0200

Hi,

  this question addresses the scenario, in which a BGP update contains 
an AS_SET. According to draft-ietf-sidr-pfx-validate-01, the variable 
origin_as would be defined as "NONE". In case of a valid certificate for 
the prefix, the prefix validation function would return "INVALID".

  BGP updates including an AS_SET with a valid certificate would never 
be valid. Correct? This seems a bit rough. Can you clarify the reason 
behind? I would expect that if a valid record for at least one origin AS 
within the AS_SET exists, the funcion will return "VALID".

Thanks
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Ruediger Volk <[email-masked]>
Date: Mon, 27 Jun 2011 16:34:08 +0200

> be valid. Correct?

  > This seems a bit rough. Can you clarify the reason 
no, as consequence of your criterium for VALID, it would get very easy
to spread VALID routes with a short prefix by doing the proxy aggregation
including one AS that has a ROA for some more specific...
(in the extreme ROA for a /128 would VALIDate a ::/0, or say 2000::/3,
or an aggregate for a very large block of your RIR's IPV6 space)

If we wanted to support proxy aggregation and the related AS_SET
the ROA to check for VALIDity would be one matching exactly the aggregate
for the origin AS of the aggregator. Fiddling and fixing with the 
different cases (beware of optional attributes!) certainly allows
for implementations to get it wrong (and create unwanted test
requirements/efforts); seems nobody stepped forward with a convincing
case really needing the AS_SET.

Gruss,
  Ruediger

Ruediger Volk

Deutsche Telekom AG -- Internet Backbone Engineering

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 27 Jun 2011 16:36:27 +0200

On Mon, Jun 27, 2011 at 04:06:22PM +0200, Matthias Waehlisch wrote:
| Hi,
| 
|   this question addresses the scenario, in which a BGP update contains 
| an AS_SET. According to draft-ietf-sidr-pfx-validate-01, the variable 
| origin_as would be defined as "NONE". In case of a valid certificate for 
| the prefix, the prefix validation function would return "INVALID".
| 
|   BGP updates including an AS_SET with a valid certificate would never 
| be valid. Correct? This seems a bit rough. Can you clarify the reason 
| behind? I would expect that if a valid record for at least one origin AS 
| within the AS_SET exists, the funcion will return "VALID".

depends ... - my understanding of the logic for extracting the
"to-be-validated" AS is something alike:

  If aggregator is present and right-most AS segment type is AS-Set,
  then use aggregator AS for validating,
  else if if right-most AS segment type is AS-set -> result: not found
  else use right-most AS for validating

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 27 Jun 2011 12:18:15 -0400 (Eastern Daylight Time)

>  then use aggregator AS for validating,

That rule was proposed at one point but discarded.

The current rule is that a route containing an AS_SET is not to be 
considered "valid".

The text in draft-ietf-sidr-roa-validation-10

    A route's "origin AS" is defined as follows: If the final path
    segment of the AS_PATH is of type AS_SEQUENCE, the "origin AS" is the
    first element of the sequence (i.e. the AS in the rightmost position
    with respect to the position of octets in the protocol message).  If
    the AS_PATH contains a path segment of type AS_SET, indicating that
    the route is an aggregate, then the "origin AS" cannot be determined.

(Note that this is even harsher than judging just the 
/right-most/final/least recently added/whatever/ path segment - it says if 
the AS_PATH *contains* an AS_SET, then the origin AS "cannot be 
determined.")

The subsequent table and steps on page 5 can lead to a decision of "not 
found" or "invalid" but not a decision of "valid":

       3.  If the route's origin AS can be determined and ...
           ...
           .......................................... then the procedure
           halts with an outcome of "valid".

Since the origin AS can not be determined, this step can not produce an 
outcome of "valid".

--Sandy

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 27 Jun 2011 12:21:51 -0400 (Eastern Daylight Time)

Forgot to say....

Since I'm speaking on chair judgement of group consensus, this is..

--Sandy, speaking as wg chair

On Mon, 27 Jun 2011, Sandra Murphy wrote:

> The current rule is that a route containing an AS_SET is not to be considered 
> "valid".
>
> (Note that this is even harsher than judging just the /right-most/final/least 
> recently added/whatever/ path segment - it says if the AS_PATH *contains* an 
> AS_SET, then the origin AS "cannot be determined.")
>