Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

On 14/04/15 21:31, Michael Richardson wrote:
> 
> Stephen Farrell asked:
>> Please correct me if I'm getting this wrong, I honestly may have forgotten
>> the plan. My understanding was that RPL and RFC 7416 etc. were approved on
>> the basis that you needed to get to specific applications of RPL before you
>> could sensibly specify interoperable security with automated key management
>> (AKM) as is clearly required by BCP107 and as has been discussed between
>> security ADs and the ROLL WG numerous times. This is going back to the 2010
>> discuss from Tim Polk that I inherited in 2011, hence me being uncertain if
>> I remember the plan for sure;-) In any case it seems to me that this draft
>> also doesn't get us to the point where we have a defined way to do AKM
>> (Again, sigh.) I also have a set of comments on that below that I won't
>> make into specific discuss points (at least until we figure out or
>> re-discover the plan).
> 
>> So, with that context, and with real regrets for sounding like an old and
>> broken record, the discuss point: why is this not the ROLL WG draft where
>> we finally get to specify AKM for RPL? If your answer is that this is just
>> an applicablilty statement then I'll ask why it's going for proposed
>> standard, and when to finally expect the AKM spec for RPL (for this
>> application).
> 
> BCP107 certainly does ask for automatic key management when keys are going to
> be used.  The part of the plan that is perhaps not so clear is that we have
> yet to have anyone say that they intend to use layer-3 keying in for RPL.
> 
> The intention of having the security being precisely specified in the
> applicability statements was so that we would know if layer-2 security was
> being used, or if there was a layer-3 security being used.
> If there is layer-3 security, then BCP107 would demand that we have an AKM for it.
> 
> In reading section 7 again just now, I see how things went wrong... Some text
> seems to have snuck into section 7(.0) that tries to sit on the fence, so I
> propose to remove paragraphs 3 and 4 of that section and say instead:
>     "This document mandates that a layer-2 mechanism be used during initial
>      and incremental deployment. Please see the following sections."
> 
> Section 7.1, is quite clear that PANA is being specified to carry EAP
> messages for a 1x bootstrap into layer-2 security.    That this is the
> default position of this document.  I have tried to persuade the authors to
> be clearer and less speculative. While I'm thrilled that they like the
> methods 6tisch is considering, I'd prefer to remove the paragraph "New
> approaches...".
> 
> I would like prefer that this document was even more precisely about what
> kind of 15.4 security is being used, either directly profiling the relevant
> parts of the 802.15.4 specification, or by indirect reference to something
> that does.

Thanks Michael. I agree that a profile or applicability statement can
certainly go for all security "below" the IP layer in which case we
don't have a direct application of BCP107. It does of course raise
some other issues about interop (making precise refs as you say) and
about how or whether you can authenticate RPL routers as such. I guess
that latter is via PANA, which I'd need to read up on.

Anyway, seems like the best thing here is for the fixes you've spotted
above to be done along with any others from the IESG review and then
for me to go over it again in the light of your mail. But do say if
there's a better plan.

Cheers,
S.


> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>