Mehmet, Thanks very much for your feedback.
See my comments in lines. > 在 2017年6月21日，14:07，Mehmet Adalier <[email protected]> 写道： > > In my opinion: > > 1) Irrelevant of the underlying hash function, BGPSec assertions based on > “only with matching SKI” should not be recommended/possible I believe that SKI collision issues is an inherited problem from SHA-1, not an issue SLURM brings about. Nevertheless, I agree with your opinion since SLURM is intended to be a sort of RPKI safeguard in local networks. > 2) Regarding keys, “only in combination with an asserted ASN for that key,” > not on the key alone I think it’s reasonable to make it obliged to do filtering on the SKI in combination with an asserted ASN. We authors will be figuring out how to get this done after WGLC. Di > > mehmet > > On 6/20/17, 8:38 PM, "sidr on behalf of Sandra Murphy" <[email protected] > on behalf of [email protected]> wrote: > > 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/sidr >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
