Subject: Re: [sidr] [Idr] 1 WG call for Review draft-ietf-sidr-origin-validation-signaling-04 - RFC4271 changes

From: <[email-masked]>
Date: Sat, 14 Jun 2014 16:57:08 +0000

Hi Keyur,

> From: Keyur Patel (keyupate) [mailto:[email-masked]] > Sent: Saturday, June 14, 2014 9:07 AM
> 
> Hi Bruno,
> 
> 
> On 6/13/14 2:02 AM, "[email-masked]"
> <[email-masked]> 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?

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-masked]> 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-masked]
> >> > 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.

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Sun, 15 Jun 2014 01:00:16 +0000

Hi Bruno,

>Looks good. Could you please add this in the draft?

Sure.

Regards,
Keyur
>__________________________________________________________________________
>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,
>information that may be protected by law;