Hi Sandy,
There is no reverse direction.
What do you mean there is no reverse direction ?
Sriram said:
"When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of
the BGPSEC island."
That means that there is EBGP peering at the two ASes which on one side
supports BGPSEC on the other does not.
In order to establish any form of bidirectional communication sites on
the left need to know how to reach sites on the right and vice versa.
So your below "Don't worry, no problem" directly means "no
reachability". I am afraid there is slight problem with that.
Best regards,
R.
speaking as regular ol' member
There is no reverse direction.
Incoming paths that are unsigned are not propagated by bgpsec
speakers as signed paths.
And intradomain BGP speakers do not use bgpsec (ebgp sessions only).
And AS4_PATH is not needed in bgpsec speakers - who are assumed to be
4-byte aware.
So no need to worry about ASBRs, flag days, etc. Don't worry, no
problem.
--Sandy, speaking as regular ol' member.
________________________________________ From: [email protected]
[[email protected]] on behalf of Robert Raszuk
[[email protected]] Sent: Monday, April 09, 2012 12:29 PM To: Sriram,
Kotikalapudi Cc: [email protected] List; [email protected] Subject: Re: [sidr]
[Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening&
lengthening
Hi Sriram,
When the update is to leave a BGPSEC island to go to a BGP-4 only
AS, then the Secure Path is easily converted to BGP-4 AS_PATH at
the edge of the BGPSEC island.
What happens in the opposite direction ? How AS_PATH/AS4_PATH can be
converted to BGPSEC_Path_Signatures without all necessary
information present at the ASBR at any arbitrary Autonomous System ?
Are you going to propose NULL signatures ?
How are you planning on a flag date where all ASBRs in the Internet
are BGPSEC complaint ?
Why one needs to upgrade also all P routers (intra domain BGP
speakers) to be BGPSEC complaint provided he is not using BGP as an
overlay today?
If you think removal of AS_PATH/AS4_PATH is helpful in any way the
much simpler would be to define new set of AFIs and call it "SECURED"
leaving current AFI 1 and AFI 2 unchanged BGP protocol wise.
Thx, R.
The updates in a BGPSEC island can be BGPSEC (i.e., signed) or
BGP-4 (i.e., unsigned). In either case, the update necessarily has
AS-path info. If the update is BGP-4 (i.e., unsigned), it has the
BGP-4 AS_PATH (mandatory) in it. If the update is BGPSEC (i.e.,
signed), then it MUST have the "Secure Path" in it. The Secure Path
is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k,
pCount-k}. Please refer to slide 8 in Matt's presentation (BGPSEC
Protocol) in Paris. The Secure Path is semantically equivalent to
the BGP-4 AS_PATH. When the update is to leave a BGPSEC island to
go to a BGP-4 only AS, then the Secure Path is easily converted to
BGP-4 AS_PATH at the edge of the BGPSEC island. Any prepend ASN
that was collapsed in BGPSEC will be repeated pCount number of
times, and any transparent route server ASN (with pCount=0) in
BGPSEC will be removed. Is this semantic equivalence (of the Secure
Path) and the guarantee of convertibility to BGP-4 AS_PATH not
enough? Should we really require in BGPSEC that the BGP-4 AS_PATH
be carried (in a pristine way) in addition to the Secure Path,
albeit at the cost of duplication and associated processing
cost/confusion? Just a honest question seeking people's opinion.
Sriram
-----Original Message----- From: [email protected]
[mailto:[email protected]] On Behalf Of Robert Raszuk Sent:
Monday, April 09, 2012 3:19 AM To: [email protected] Cc: [email protected]
List Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path
shortening& lengthening
Your analysis assumes that there a conventional BGP-4 AS_PATH
field and then there is is BGPSEC_Path_Signatures from which AS
path info can be inferred separately. This is not true in the
latest BGPSEC update format as Matt presented it in Paris.
How an optional attribute replace well-known mandatory one ?
Sorry but for such step formal IDR WG approval is necessary if
you choose to propose BGPSEC_Path_Signatures as mandatory
attribute. This is major BGP protocol change.
Documentation of partial deployment is required as well as two
interoperable implementations ;).
RFC4271:
5.1.2. AS_PATH
AS_PATH is a well-known mandatory attribute. This attribute
identifies the autonomous systems through which routing
information carried in this UPDATE message has passed. The
components of this list can be AS_SETs or AS_SEQUENCEs.
draft-ietf-sidr-bgpsec-protocol-02.txt
This document specifies a new optional (non-transitive) BGP path
attribute, BGPSEC_Path_Signatures.
Best regards, R.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
