Re: [OSPF] Authentication/Confidentiality for OSPFv2

[Stan Ratliff <sratliff at cisco.com>]

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<acee at redback.com>  
> > > 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
> > > > > > OSPF at ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/ospf
> > > >
> > > > _______________________________________________
> > > > OSPF mailing list
> > > > OSPF at ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ospf
> > > _______________________________________________
> > > OSPF mailing list
> > > OSPF at ietf.org
> > > https://www.ietf.org/mailman/listinfo/ospf
> >
> > _______________________________________________
> > OSPF mailing list
> > OSPF at ietf.org
> > https://www.ietf.org/mailman/listinfo/ospf