Hi, folks,
I think the local resource management of resource with PRKI in this draft
will be very effective and useful to secure the BGP routing of carrier network,
so I give my support to it.
Thank you!
Chongfeng
发件人: Sandra Murphy <sa...@tislabs.com>
主题: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04
日期: 2017年6月21日 GMT+8 11:38:44
收件人: Christopher Morrow <morrowc.li...@gmail.com>
抄送: sidr <sidr@ietf.org>, sidr chairs <sidr-cha...@ietf.org>
The “not have gotten much” was one request from an author, which got no
response from the working group.
Come on, folks. We can do this.
Maybe the usual increase in attention and energy of an approaching meeting will
help.
This starts a second wglc for draft-ietf-sidr-slurm-04. Since it is the second
wglc, it will be short, ending 30 Jun 2017.
Silence is not consent. Consensus for publication requires actual comment.
Read it. Speak up.
—Sandy, speaking as one of the wg co-chairs
On Jun 20, 2017, at 11:52 AM, Christopher Morrow <morrowc.li...@gmail.com>
wrote:
Howdy WG folks. this seems to not have gotten much review (after the authors
changed a bunch).. can we get some readin/reviewin/commentin going on here
please? :)
On Mon, Apr 17, 2017 at 2:06 PM, Tim Bruijnzeels <t...@ripe.net> wrote:
Dear WG
One thing the authors noted was that there may be discussion needed around the
filtering of BGPSec assertions based on matching SKI - as the document
currently says. This was added mainly in an attempt to make the spec feature
complete and give an operator full freedom on filter rules.
SKIs use SHA-1. And recently it has been shown that SHA-1 collisions can be
generated. This could lead one to believe that filtering of assertions based on
a SKIs may not be a good idea. However, it should be noted that such collisions
are probably irrelevant here. A ‘malicious' CA can always issue another router
certificate for an existing (and requested) router certificate SKI and public
key. So ‘collisions’ can exist anyway and a more secure hashing algorithm would
not help.
The more fundamental question here is if it is really useful to have filtering
based on the key itself - and if so - should it be possible to filter on the
key alone (as the draft allows) or only in combination with an asserted ASN for
that key (also allowed in this draft)?
As said it was mainly added for feature completeness, but it would be good to
hear from this WG what the thoughts are. Personally I don’t see a big issue
here - and would leave it to operators to use the options as they see fit. But
if there are concerns and there is no clear use case then I for one would be
happy to take it out again in which case BGPSec assertions can only be filtered
on matching ASN.
Cheers
Tim
On 10 Apr 2017, at 17:49, Sandra Murphy <sa...@tislabs.com> wrote:
The authors of draft-ietf-sidr-slurm-04, "Simplified Local internet nUmber
Resource Management with the RPKI”, have indicated that they believe the
current version includes all wg comments and is mature and ready for working
group last call.
This message starts a WGLC for draft-ietf-sidr-slurm-04. The WGLC will end 24
April 2017.
The draft can be found at https://tools.ietf.org/html/draft-ietf-sidr-slurm-04
or https://datatracker.ietf.org/doc/draft-ietf-sidr-slurm/.
Please reply to the list whether the document is ready for publication or you
have comments that you think should be addressed.
Please do read and respond to the list. Remember that responses are required
to gauge consensus, silence is not consent.
—Sandy, speaking as wg co-chair
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
