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.
_______________________________________________
Idr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
