Re: [OSPF] Authentication/Confidentiality for OSPFv2

[Anton Smirnov <[e-mail]>]

   Hi Stan,
   I appreciate your concern that IPsec is not an option for MANET
deployments but then I can't believe OSPF traffic is the only thing
there which must be protected. Because if user traffic requires
encryption then having OSPF encrypted by its own protocol means is not
really solving any issue. In this case problem has to be addressed lower
in hierarchy, probably devising encryption scheme on radio link level.

   So far I have never seen valid deployment scenario when routing
protocol has to have protection stronger than traffic. Without
understanding of target deployment scenario this looks like me-too effort.

Anton



Stan Ratliff wrote:
> Using IPSec is great (painful, laborious, voluminous configuration
> aside) if you have a wired network, and static partners. It isn't so
> great if you're trying to deploy an ad-hoc network, and you're not
> really sure from moment-to-moment which of your potential partner
> routers you make be needing to establish an adjacency with. So, IPSec
> doesn't really work for me.
> 
> Regards,
> Stan
> 
> On Aug 25, 2009, at 1:37 PM, Vishwas Manral wrote:
> 
>> Hi Acee,
>>
>> Though I mostly agree with Paul. The advantage of having something at
>> the IPsec level is that we do not require protocol specific extensions
>> as long as IPsec meets the needs as we move forward. an example of
>> this could be automatic Keying mechanism rather than manual keying.
>>
>> Thanks,
>> Vishwas
>>
>> On Tue, Aug 25, 2009 at 10:21 AM, Acee Lindem<[e-mail]> wrote:
>>> Hi Paul,
>>>
>>> On Aug 19, 2009, at 12:58 PM, Paul Wells wrote:
>>>
>>>> Hi Acee,
>>>>
>>>> Before we make this a working group document I'd like to hear what real
>>>> problem in OSPFv2 this proposal is addressing.
>>>>
>>>> With draft-ietf-ospf-hmac-sha we are upgrading the authentication
>>>> algorithms used by OSPFv2 to the same ones commonly used with IPSec.
>>>> While
>>>> the optional use of AH does authenticate additional bits of the IP
>>>> header,
>>>> I'm not sure I see a significant benefit in that. On the other hand,
>>>> we lose
>>>> the replay protection we currently have in OSPFv2.
>>>
>>> This would not replace the existing OSPFv2 authentication. Rather, it
>>> would
>>> augment it.
>>>
>>>
>>>>
>>>> The only new capability I see is the option of encrypting the protocol
>>>> traffic while, presumably, leaving everything else in the clear. In my
>>>> opinion if you really care about confidentiality you'll run everything,
>>>> including OSPF, through an IPSec tunnel.
>>>
>>> That's a valid question? What is the group feeling on this?
>>>
>>>
>>>>
>>>> I'd rather see the WG spend it's time improving RFC 4552 by allowing
>>>> for
>>>> automated rekeying (at least on P2P links) rather than simply
>>>> copying the
>>>> existing OSPFv3 spec to OSPFv2.
>>>
>>> Much of what is going on in this space is not within the charter of
>>> the OSPF
>>> WG. With respect to P2P links, I've thought about defining a mode of
>>> operation that would relegate OSPF(v3) topologies to P2P and P2MP
>>> allowing
>>> the use of IKEv2 for automated rekeying. In fact, it was one of those
>>> ideas
>>> I meant to propose at an OSPF WG meeting but never got around to it.
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>> Acee Lindem wrote:
>>>>>
>>>>> For some time we've discussed adding IPsec support for OSPFv2
>>>>> analogous
>>>>> to what we have for OSPFv3. The draft subject draft describes how
>>>>> we'd build
>>>>> on the OSPFv3 support to support OSPFv2:
>>>>>   http://www.ietf.org/id/draft-gupta-ospf-ospfv2-sec-01.txt
>>>>> What are the current thoughts as far as adding this as a WG document?
>>>>> Thanks,
>>>>> Acee
>>>>> P.S. The formatting issues will be fixed in the next
>>>>> revision._______________________________________________
>>>>> OSPF mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf