Re: [OSPF] Authentication/Confidentiality for OSPFv2

[Stan Ratliff <[e-mail]>]

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