Re: When can NLRI and Withdrawn Route info be modified?

[Paul Traina <[e-mail]>]

  From: Brad Smith <[e-mail]>
  Subject: Re: When can NLRI and Withdrawn Route info be modified? 
  Hello Paul,
  
  Thanks for the response.
  
  > The protocol does not specify when it can or can't be modified.  Manual
  > configuration can always modify something (you can lie about your view
  > of the world if you want to be evil).
  
  A particularly apropos example... my interest is, in particular, related
  to securing BGP (yes, I'm still muddling around with this problem:).
  
  Is there any reasonable constraint that can be put on when the NLRI can
  be modified and who can do it?  E.g. would it be reasonable to say
  that only an originating or aggregating BGP speaker can/should modify
  the NLRI (and therefore Withdrawn Route) information?

Yes and know.  There are parts of an attribute that are typically only
set by the originating AS, such as "origin code", all transitive attributes
are typically set by the originator,  but it is common for some of these
attributes to be modified by others (e.g. the community attribute is
an optional transitive attribute, but may be modified).  Rather important
information, like the next-hop address or local-pref is non-transitive, so
you need a way to authenticate those too (however it may be sufficient to
rely on peer-peer authentication for non-transitive attributes).

I'd say the parts of the attribute I'd most like to see protected or
authenticated are the AS path (which may require multiple signatures) and
the prefix itself.
  
  The underlying issue here is, as a BGP speaker having to select a route,
  who may I have to trust as the source of this information (seems pretty
  clearly to be either the originator or last aggregator of the path), and
  to what granularity does this authentication need to be expressed (hopefully
  the NLRI and Withdrawn Routes can be authenticated as a whole by e.g. the
  originator or last aggregator, my fear is they need to be authenticated on
  a per destination network basis by the last BGP speaker in the path that
  chose to muck with them).
  
  > Is your question, when can things be aggregated and what do you have to do?
  > If so, you can always choose to aggregate a route if you have information
  > about some more specific prefixes of that canidate aggregate.  You can take
  > this to the extreme of generating what we used to think of as a "default"
  > route.
  > 
  > When you aggregate, you may, or may not, withdraw the more specific routes.
  > Your choice again.  Obviously, it makes sense to withdraw more specific
  > routes in almost all cases.  If you advertise a hunk of NRLI, you should
  > be prepared to withdraw that same hunk if the conditions that created that
  > aggregate change.
  
  Understood.
  
  > When do you use AA?  When you create an aggregate of more specific NRLI, th
>>e
  > preferred choice is to combine the AS paths of the more specific NRLI into
  > an AS set and advertise that set.  If for some reason, you do not create a
  > set that contains complete information of all ASs in the paths you
  > aggregated,  you add the AA attribute.
  
  The answer to the following may be obvious, by definition, but I want
  to make sure I understand... is it true that an ATOMIC_AGGREGATE will
  only be generated in a situation where an AGGREGATE attribute would
  also be generated? (Even writing this I realize that it could be read
  as "is it true that aggregation is done only when aggregation is being
  done"... but I'll leave the question on the table:).

There is no such thing as an aggregate attribute.  There's no real way to
tell if a route is an aggregate or not.  There are intelligent guesses
(does it have an AA, or are there any AS sets in the path), but those aren't
sure things and should not be relied upon.
  
  > *My* reading of the text is, if, for any reason, you lose AS path informati
>>on
  > in the process of generating an aggregate, you must set AA to indicate that
  > information has been suppressed.
  > 
  > Does anyone actually do anything with AA?  Not really as far as I know.
  
  Understood.
  
  Again, many thanks for your answers.

No prob, I hope you come up with some interesting ideas.  Feel free to bounce
them off of me or anyone else in the group, even if you think they're wild
or half-baked.
  
  Brad