[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA] WGLC for draft-ietf-dna-frd-02.txt



Hi Wassim,

>>(Hmm, later I see it has what seems like a protocol change regarding
>>Ownership Proof. That would seem to imply standards track. What is
>>it?)
>>    
>>
>
>=> Maybe we should move these two sections to appendix to avoid any
>confusion.
>  
>
I don't think that helps. Either we have a complete spec in this
document, or we have normative references to other specs that
define these things. If we go for the normative references, then
those should be RFCs or at least we should be reasonably certain
that they will become RFCs in a timely fashion.

Alternatively, if the protocol changes are not really needed
for the DNA spec then they can be pursued separately.
In general, security is not something that can be pushed
off this way, however. Though this case is a bit special.
I have not formed a strong opinion yet if the caching actually
is a problem for SEND. Or whether its a problem depends
on how you perform FRD. My first reaction would be to
avoid the problem, since some of the solutions in the draft
do not appear to have a problem with SEND.

>>Second, the document title is misleading. Rather than calling this
>>"fast router discovery", I think it should be called something like
>>"triggered router discovery", since the whole point is to have the
>>sending of RAs triggered by a link up type event.
>>    
>>
>
>=> Thank you for raising this point. I agree the title should reflect the
>triggering process but also the consequence of such triggering.
>  
>
I like the new title suggestion too.

>>One issue with RA proxying is that the info in a cached RA may be old
>>and invalid. RAs include lifetimes in units relative to "now". Caching
>>an RA for (say) 15 minutes means that the lifetime information in that
>>RA is now potentially very incorrect. Are proxies supposed to muck
>>with lifetimes and decrement them in real time? Note that this would
>>presumably break SEND (and any other way of securing RAs). I don't see
>>discussion of this anywhere.
>>    
>>
>
>=> Proxies don't decrement lifetime. In practice, RA information seldom
>changes. Usually routers send the same RA again and again.
>  
>
That lifetimes are not decremented does help with
the SEND impacts. But then you have another
issue that the scheme is limited to situations where
keeping the lifetimes constant does not harm anyone.
What if you see an RA at time t_0 and a host at time t_1,
with the prefix lifetime in the RA < (t_1 - t_0)? Would
you need an applicability statement or even protocol
mechanisms to avoid such situations?

--Jari