comments/suggestions/critique welcome.
Sriram
From: internet-dra...@ietf.org
Sent: Monday, March 14, 2016 11:28 PM
To: Brian Dickson; Montgomery, Douglas (Fed); Keyur Patel; Andrei Robachevsky;
Sriram, Kotikalapudi (Fed)
Subject: New Version Notification
I read the draft. A few comments:
1. RPKI validation refers to checking cryptographic integrity of the RPKI
objects such as certs, ROAs, etc.
What you intend to signal from RS to peers is prefix-origin validation results
(RFC 6811).
s/RPKI validation results/ prefix-origin validation results/g
I have read the draft and support adoption.
Sriram
-Original Message-
From: sidr [mailto:sidr-boun...@ietf.org] On Behalf Of Sandra Murphy
Sent: Friday, March 11, 2016 12:06 PM
To: sidr
Cc: Sandra Murphy
Subject: [sidr] adoption call for draft-kent-sidr-adverse-actions-02
This starts a
>Please respond on the list to say whether you support adoption of this work as
>a working group work item AND whether you will participate in the discussion.
yes and yes
Sriram
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo
This new version incorporates some editorial changes based on comments
received from Matthias Waehlisch (shepherd for this document).
All the references have been updated.
In couple of places, there were repetitions of some sentences. That has also
been fixed.
Sriram
___
Many thanks to John Scudder for a very careful review of version-15 of the
draft.
He offered an excellent set of editorial comments to the document editors and
shepherd.
His email came in literally milliseconds after I had uploaded version-16 two
days ago.
Matthias asked if the editors could mak
>A newer ROA competes with an older ROA if the newer ROA points to a
different ASN, contains the same or a more specific prefix, and is
issued by a different CA.
For DDoS mitigation service, (as an example) a /16 prefix owner may create
(well in advance)
two new ROAs for more specific /17s
I have given it a quick read. Reads good.
I support publication.
Nit:
BPKI acronym is used earlier but the expansion (Business 'PKI') is stated only
in Section 2 for the first time.
I think mentioning the expansion on first use of the acronym in the
Introduction would be good
-- you may take c
.
Sriram
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, August 18, 2016 10:33 AM
To: Matthew Lepinski ; Sriram, Kotikalapudi (Fed)
Subject: New Version Notification for draft-ietf-sidr-bgpsec-protocol-18.txt
A new version of I-D
I think using the term "RPKI anomalies" is another choice here. It's kind of
neutral about cause/intention.
Advising/alerting the user community about -
RPKI anomalies may arise due to various reasons.
It could be due to fat fingers, negligence, or actions by your service provider
or law enforcem
I read the draft once again. I support publication.
Found a minor typo in the last paragraph on p.15 (can be dealt with during RFC
editor review process):
s/the loss of on IP address prefix from the VRS-IP/the loss of one IP address
prefix from the VRS-IP/
Sriram
__
Hi Alvaro,
Thank you for the review and the excellent set of comments.
We (editors/authors) will consider all you comments
and respond / make changes in the document soon.
>The biggest concern I have with this document is the lack of an
>Operations and Management Considerations Section –
It wo
From: internet-dra...@ietf.org
Sent: Sunday, November 27, 2016 9:30 AM
To: Matthew Lepinski; Sriram, Kotikalapudi (Fed)
Subject: New Version Notification for draft-ietf-sidr-bgpsec-protocol-19.txt
A new version of I-D, draft-ietf-sidr-bgpsec-protocol-19.txt
has been successfully submitted by Kotikal
Hi Alvaro,
Thank you very much for this thorough and detailed set of comments.
They greatly help improve the clarity, accuracy, and presentation in the
document.
I have worked with each of the comments and incorporated changes accordingly
in the document. Please see version-19 that was just su
>Hi! I think the only item left is the Confederations one…and we might be
>speaking past each other.
Thanks, Alvaro. My comments are marked with [Sriram-3].
[Sriram-3] I understand now your main comment about confederation. I think
there are two ways to address it (of course I hope other p
Thinking about it some more, I now find that your proposed solution of adding a
signature with pCount = 0 at the border of the confederation works well and
fully addresses these two concerns (the second concern is new).
(1) Your proposed solution addresses the concern you brought up in an earlie
Hi Alvaro,
I said in my previous post:
"(2) It also keeps confed ASes from failing to validate properly the signature
injected at the boundary."
I retract my observation that the document had a problem in that
"confed ASes fail to validate properly the signature injected at the boundary."
Russ Housley had suggested these changes (#1 and #2 below) as part of his
SecDir review.
But he also suggested to me to put it out on the mailing list so that
implementers in particular and anyone having an opinion can have a say.
Russ's comment:
Minor:
#1
In Section 3.2, the Signature Leng
: Matthew Lepinski; Sriram, Kotikalapudi (Fed)
Subject: New Version Notification for draft-ietf-sidr-bgpsec-protocol-21.txt
A new version of I-D, draft-ietf-sidr-bgpsec-protocol-21.txt
has been successfully submitted by Kotikalapudi Sriram and posted to the
IETF repository.
Name: draft-ietf
Hi Alvaro,
Please see my comments inline below.
>From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
>Sent: Friday, December 09, 2016 5:00 PM
….
>Hi! I think the only item left is the Confederations one…
….
>Yes, I agree that the collusion problem is one that (as you mentioned below)
>
>From: Randy Bush
>Sent: Thursday, December 29, 2016 6:02 PM
>that is not the core of the problem. the bgpsec protocol doc has to
>specifically say that the public AS upon receiving the update from the
>private AS
> o if the private signed to the public, public should check sig, then
>strip
Hi Mirja,
>I actually might be mixing this up with some discussion about DNSsec a while
>ago, where the problem was that once enable others will remember that it was
>supported and will not accept non secured requests anymore.
>But as we are talking about this, could there be a similar case her
Hi Peter,
>At Tue, 3 Jan 2017 09:39:07 +0100,
>Peter Hessler wrote:
>>
>> I'm currently not using bgpsec (or rpki for that matter). BUT, if there
>> was no path to go back, I would never ever use it. Destroying my ASN
>> because I wasn't ready to migrate is a straight-up No Go(tm).
>yup, I thi
Stephen,
Thank you for the detailed review and comments.
Please see my responses marked with [Sriram] inline below.
[Sriram] Your DISCUSS points (1) and (3) were already
discussed /being discussed in separate threads.
> (2) Figure 8: It seems to me to be an error to omit the
signer's ASN from th
Keyur,
Thank you for taking the time to read and offer comments.
I find the comments very insightful and helpful.
My comments are marked with [Sriram] below.
>From: Keyur Patel ke...@arrcus.com
>Sent: Wednesday, January 4, 2017 5:53 PM
>The document is well written, easy to read and follow.
My previous post of this message seems to have line wrap issue.
Resending ... hopefully this avoids that issue. - Sriram
---
Keyur,
Thank you for taking the time to read and offer comments.
I find the comments very insightful and helpful.
My comments are marked with [Sriram
Stephen,
Please see responses inline below.
>>[Sriram] Signer's ASN is indeed included in the signed data.
>> In Figure 8, "Secure_Path Segment : N" corresponds
>> to the signing AS (current AS) and that is where the
>> signer's ASN is included along with its pCount and Flags.
>Hmm. That's the t
Stephen,
Please see response below.
>From: sidr on behalf of Stephen Farrell
>
>Sent: Wednesday, January 4, 2017 4:45 PM
>To: Montgomery, Douglas (Fed); Russ Housley
>Hiya,
>On 04/01/17 21:39, Montgomery, Douglas (Fed) wrote:
>> The RPKI validating caches *are* the relaying parties for BGPsec
Hi Alissa,
Sorry for the delay in responding.
Thank you for your comments. My responses inline below.
I have already made the changes (as noted below)
in my editor copy of the draft version-22.
>From: Alissa Cooper [mailto:ali...@cooperw.in]
>Sent: Wednesday, January 04, 2017 11:21 AM
…
> - Fig
Hi Alexey,
My comment in line below.
>From: Alexey Melnikov [mailto:aamelni...@fastmail.fm]
>Sent: Thursday, January 05, 2017 4:57 AM)
>
> > On 5 Jan 2017, at 03:19, Suresh Krishnan
> > wrote:
> >
> >> On 01/04/2017 09:38 AM, Sean Turner wrote:
> >>
> On Jan 4, 2017, at 05:09, Randy Bu
on 22 (to be uploaded in a
couple of days).
Sriram
From: Suresh Krishnan
Sent: Wednesday, January 11, 2017 10:53 PM
To: Alexey Melnikov
Cc: Sriram, Kotikalapudi (Fed); sidr wg list; Sean Turner; sidr chairs;
draft-ietf-sidr-bgpsec-proto...@ietf.org; The IE
Hi Spencer,
Please see my comments inline below marked with [Sriram].
I have made changes in the document in response to your comments.
You’ll see them in version-22 (to be uploaded in the next few days).
>Perhaps I'm just having a good day, but this is
>one of the clearest BGP-related specifi
Hi Mirja,
Sorry for the delay in replying.
Thank you for your careful review, and the detailed and helpful comments.
Please see my responses inline below marked with [Sriram].
Changes reflecting your suggestions as discussed below
have been incorporated in the forthcoming version-22.
>F
Hi Ben,
Sorry for the delay in responding.
Thank you for the review and very helpful comments.
Please see my responses inline below.
The changes mentioned below that reflect your comments/suggestions
are already incorporated in the forthcoming version-22.
>-2: draft-ietf-sidr-bgpsec-protocol ex
This revision addresses the comments from the IESG reviewers,
and also the comments from Keyur (RTGDIR review) and
Alvaro (some new comments in the context of Keyur’s comments).
It also addresses comments from Oliver and Randy (mainly
suggestions for making Sections 4.3 and 7 a bit crisper and mo
Hi Alvaro,
... snip ...
Alvaro wrote:
>>I don’t have an objection for this behavior, but I think
>>we should make the WG (and idr!) aware of the change
>>and get their comments (if any) before I approve the publication.
Keyur responded:
>#Keyur: Ack. Though I was only requesting some text clari
grow much larger.
But I'll see if Alvaro's wording can be additionally
folded into the document in an appropriate place.
Thank you.
Sriram
From: Mirja Kuehlewind (IETF)
Sent: Tuesday, January 17, 2017 10:52 AM
To: Alvaro Retana (aretana)
Cc: S
Ben,
Thank you. Please see my response inline below.
>>>
>>> - 8.4, last paragraph: The text describes a replay attack, and
>>> delegates
>>> the mitigation solution to. This is an
>>> informational reference; it draft-ietf-sidr-bgpsec-rollover
>>> seems like it should be normative.
>>
>> The
the WG list.
Please read the proposal below, and share your thoughts. Thanks.
Sriram
From: Sriram, Kotikalapudi (Fed)
Sent: Monday, March 13, 2017 4:57 PM
To: Alvaro Retana (aretana)
Subject: BGPsec draft and extended messages
Hi Alvaro,
Just trying
>> I think it makes sense to omit the extended message feature, given the
>> use of ECDSA P-256.
>unfortunately, existing bgp data and simple arithmetic would seem to say
>otherwise.
We are focusing here on the size of the BGPsec_Path attribute.
As I wrote in the rationale part in my other
Wes,
Comments inline below marked with [ks].
>
>Being pragmatic, I understand that the risk is low for exceeding the max size
>without extended message support based on the average AS-path length, but I
>have concerns about the suggested solution that treats unsigned updates as a
>fallback p
Wes,
Thanks for the clarification. My comments below.
….. snip ….
>WG] My original email was insufficiently precise when expressing my concern on
>this, as it was written in relative haste. I’ll try again. I always
>interpreted this as allowing for updates that were never secured (because the
Inviting comments especially from GROW WG folk (network operators).
Please look at this and address the question posed at the end. Thank you.
The most common form of route leak occurs when multi-homed
customer AS-C receives a route from its transit provider AS-A
and leaks it to another transit p
>> SIDR/GROW/IDR and well documented in IDR (see Section 4)
>> (
>> https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06
>> ).
>> The solution involves AS-A setting a field (in an optional transitive
>> attribute)
>glad you liked the attribute approach well enough to pl
Hi Matt,
I think slide 4 of this presentation (SIDROPS, IETF 98) addresses your
questions/concerns:
https://www.ietf.org/proceedings/98/slides/slides-98-sidrops-decoupling-bgpsec-documents-and-extended-messages-draft-00.pdf
Please take a look at slide 3 also (BGP & BGPsec update sizes).
Als
27, 2017 12:02 PM
To: Matthew Lepinski ; Sriram, Kotikalapudi (Fed)
Subject: New Version Notification for draft-ietf-sidr-bgpsec-protocol-23.txt
A new version of I-D, draft-ietf-sidr-bgpsec-protocol-23.txt
has been successfully submitted by Kotikalapudi Sriram and posted to the IETF
>Thanks for addressing our concerns. With the new changes in place I believe it
>is ready to advance, “ship it”
+1
Yes, thank you, Sean.
As Oliver mentioned, the comments you received from him were combined comments
from the two us.
I have looked over the new version you sent us. Looks good to
Chris,
I think you should wait for Sean to upload version-14.
He sent it to me and Oliver but not uploaded yet.
Sriram
From: Christopher Morrow
Sent: Wednesday, October 18, 2017 3:07 PM
To: Sriram, Kotikalapudi (Fed)
Cc: Sean Turner; Borchert, Oliver
David, Di, Tim:
These are minor comments in alignment with Alvaro’s.
Alvaro wrote:
>M4. References:
>M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be Normative.
>M4.3. [minor] Please update the references according to the Nits [1].
>[1]
>https://tools.ietf.org/idnits?url=https
In its draft form, the BGPsec design discussions document was
found useful and cited many times during sidr/sidrops/idr discussions on
BGPsec.
It is now published as an Independent Submissions RFC:
https://tools.ietf.org/html/rfc8374
The authors/designers/advocates team wishes to thank
the
50 matches
Mail list logo
