Subject: [OSPF] Authentication/Confidentiality for OSPFv2

From: Acee Lindem <[email-masked]>
Date: Wed, 19 Aug 2009 11:18:44 -0400

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.

---

From: Michael Barnes <[email-masked]>
Date: Wed, 19 Aug 2009 08:29:13 -0700

Hi Acee,

There is at least a little end user interest in this, I think it should 
be a WG document.

Regards,
Michael

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:
> 
> P.S. The formatting issues will be fixed in the next 
> revision._______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Paul Wells <[email-masked]>
Date: Wed, 19 Aug 2009 11:58:43 -0500

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.

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.

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.

Regards,
Paul

---

From: Acee Lindem <[email-masked]>
Date: Tue, 25 Aug 2009 13:21:22 -0400

Hi Paul,

On Aug 19, 2009, at 12:58 PM, Paul Wells wrote:

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

> you'll run everything, including OSPF, through an IPSec tunnel.

That's a valid question? What is the group feeling on this?

> 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

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 25 Aug 2009 10:37:15 -0700

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<[email-masked]> wrote:
>> Before we make this a working group document I'd like to hear what real
>> problem in OSPFv2 this proposal is addressing.
>>
>> 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.
>
>> 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:
>>>
>>> to what we have for OSPFv3. The draft subject draft describes how we'd build
>>> on the OSPFv3 support to support OSPFv2:
> _______________________________________________
> OSPF mailing list
> [email-masked]

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 26 Aug 2009 10:37:30 -0400

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:

>>> real
>>> IPSec. While
>>> protocol
>>> allowing for
>> the OSPF
>>>> analogous

---

From: Anton Smirnov <[email-masked]>
Date: Thu, 27 Aug 2009 13:54:07 +0200

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

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 28 Aug 2009 12:21:38 -0400

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:

>>>>> IPSec.
>>>>> While
>>>>> I'm not sure I see a significant benefit in that. On the other  
>>>>> hand,
>>>>> we lose
>>>>> allowing
>>>>> for
>>>> the use of IKEv2 for automated rekeying. In fact, it was one of  
>>>> those
>>>> ideas