[RPSEC] Informational RFC to be: draft-white-pathconsiderations-05.txt (fwd)

[Tony Tauber <[e-mail]>]

Hi folks,

There's an individual submission which is being reviewed by the IESG
and which relates to the work of this group. 
Alex has some pointed questions below.
Please apply your attention to this matter and indicate your thoughts
to the list.

Thanks,

Tony
ps.  The latest revision of the BGP Security Requirements document has
been sent to the I-D repository and should be posted soon.

--------- Forwarded message ----------
From: Alex Zinin <[e-mail]>

  The formal process suggests that we need to ask the RPSEC WG
  about this doc, specifically two questions:

   1. Whether the WG is fine with this document being published
      as an individual submission.

   2. Whether the WG has any technical comments on the contents
      of the document.

-- 
Alex
http://www.psg.com/~zinin

This is a forwarded message
From: RFC Editor <[e-mail]>
To: IESG <[e-mail]>, iesg-secretary <[e-mail]>
Cc: RFC Editor <[e-mail]>, [e-mail]
Date: Wednesday, June 15, 2005, 11:43:21 AM
Subject: Informational RFC to be: draft-white-pathconsiderations-05.txt

===8<==============Original message text===============
Resending with the correct Subject line.


On Wed, Jun 15, 2005 at 11:41:07AM -0700, RFC Editor wrote:
> IESG,
>
> This RFC-to-be was submitted to the RFC Editor to be published as
> Informational: draft-white-pathconsiderations-05.txt.
>
> Please let us know if this document conflicts with the IETF standards
> process or other work being done in the IETF community.
>
> Four week timeout is initiated (13 July 2005).
>
>
>          Considerations in Validating the Path in BGP
>
>
>  A good deal of thought has gone into, and is currently being given
>  to, validating the path to a destination advertised by BGP.  The
>  purpose of this work is to explain the issues in validating a path
>  with BGP, in the expectation that it will help in the evaluation of
>  schemes such as [SOBGP] and [S-BGP] that seek to improve path
>  validation.
>
>  There are many issues we need to consider when securing [BGP],
>  including (but possibly not limited to):
>
>  o  The autonomous system (AS) originating an advertisement indicating
>     a specific prefix (or block of IP address) space is reachable
>     within that AS is authorized, through some mechanism, to advertise
>     the prefix.
>  o  If an advertisement is withdrawn, the withdrawing AS was
>     originally authorized to advertise the prefix.
>  o  If an AS receives an advertisement, the peer sending the update
>     has a path to the destination prefix in the update.
>  o  If an AS receives an advertisement, it is authorized to transmit
>     traffic along the AS Path advertised in the update.
>  o  If a BGP speaker receives an advertisement, traffic forwarded to
>     the peer advertising the update will follow the path described in
>     the AS Path.
>  o  If an AS receives an advertisement from a peer other than the
>     originating AS, the advertising speaker is authorized to advertise
>     the entire address block within the advertisement.
>
>  We believe the first issue, proving a path from the BGP speaker
>  advertising an update containing a specific prefix to destinations
>  within that prefix, is generally provable.  The second issue, proving
>  the source of a withdraw is actually authorized to withdraw the
>  indicated routing information, is outside the scope of this draft.
>
>  This draft shows these last three assumptions cannot be held to be
>  true in a path vector routing system, such as [BGP].
>
>
> This document was reviewed for the RFC Editor by Craig Partridge.
>
>
> Sincerely,
>
> Sandy Ginoza - USC/ISI
> Request for Comments Documents


===8<===========End of original message text===========

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