Hi Bruno, On 6/14/14 9:57 AM, "[email protected]" <[email protected]> wrote:
>Hi Keyur, > >> From: Keyur Patel (keyupate) [mailto:[email protected]] > Sent: >>Saturday, June 14, 2014 9:07 AM >> >> Hi Bruno, >> >> >> On 6/13/14 2:02 AM, "[email protected]" >> <[email protected]> wrote: >> >> >> > Validity state signaling SHOULD NOT be accepted from a neighbor AS. >> >> >> >> I would agree >> > >> >I agree on the goal. >> >Now the question is how do you protect from this, if you're unstrusted >> >neighbor AS send this community over eBGP session. >> >> >> I suggest we log an error and drop the community. > >Looks good. Could you please add this in the draft? Sure. Regards, Keyur > >Thanks. >Bruno > >> >> Regards, >> Keyur >> >> > >> >> + also add that setting this extended community by manual >> >> EBGP policy should NOT be supported. >> > >> >IMO adding the text "The sender should not do that" is not a very >> >strong protection. Otherwise, we would not need any crypto signature. >> >(e.g. you should not originate a BGP route if you are not the true >> originator). >> >You can add the check on the receiver side, but this would now require >> >that all ASBR be upgraded to support this new community, before it >> >could be used. If this is the chosen path, it should be written in the >> >draft in the deployment consideration section >> > >> >> The above along with the fact that this is already non-transitive in >> >>the AS scope should solve that worry completely. >> > >> >Not yet. >> > >> >> r. >> >> >> >> On Fri, Jun 13, 2014 at 4:12 AM, Randy Bush <[email protected]> wrote: >> >> >> #Keyur: Ideally, the usage of this community should NOT be >> >> >> encouraged #across inter-as boundaries. We can add necessary text >> >> >> to reflect #that part. >> >> > >> >> > from rfc 7115, end of sec 5 >> >> > >> >> > Validity state signaling SHOULD NOT be accepted from a neighbor >>AS. >> >> > The validity state of a received announcement has only local >>scope >> >> > due to issues such as scope of trust, RPKI synchrony, and >> >>management >> >> > of local trust anchors [LTA-USE]. >> >> > >> >> > randy >> >> > >> >> > _______________________________________________ >> >> > Idr mailing list >> >> > [email protected] >> >> > https://www.ietf.org/mailman/listinfo/idr >> >_________________________________________________________ >> ______________ >> >___ _______________________________________________ >> > >> >Ce message et ses pieces jointes peuvent contenir des informations >> >confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> >exploites ou copies sans autorisation. Si vous avez recu ce message par >> >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que >> >les pieces jointes. Les messages electroniques etant susceptibles >> >d'alteration, Orange decline toute responsabilite si ce message a ete >> >altere, deforme ou falsifie. Merci. >> > >> >This message and its attachments may contain confidential or privileged >> >information that may be protected by law; they should not be >> >distributed, used or copied without authorisation. >> >If you have received this email in error, please notify the sender and >> >delete this message and its attachments. >> >As emails may be altered, Orange is not liable for messages that have >> >been modified, changed or falsified. >> >Thank you. >> > > > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
