Re: [OSPF] Authentication/Confidentiality for OSPFv2

[Stan Ratliff <[e-mail]>]

Authenticating session partners is important for mobile, ad-hoc  
networks. Having confidentiality and non-repudiation for control-plane  
traffic is extremely important as well. Deployment scenarios would be  
something like an ad-hoc network coming together to fight the all-too- 
common California wildfires. You don't want someone hacking into the  
network, pretending to be a routing node. The same notion applies to  
military networks.

Regards,
Stan


On Aug 27, 2009, at 7:54 AM, Anton Smirnov wrote:

>
>   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