Re: draft-ietf-ospf-ospfv3-auth-04.txt

Suresh Melam <nagavenkata.melam@NOKIA.COM> Tue, 13 July 2004 18:07 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29829 for <ospf-archive@LISTS.IETF.ORG>; Tue, 13 Jul 2004 14:07:09 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00E1409B@cherry.ease.lsoft.com>; Tue, 13 Jul 2004 14:07:08 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25770373 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jul 2004 14:07:07 -0400
Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jul 2004 14:07:06 -0400
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DI75s15084 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 13 Jul 2004 21:07:05 +0300 (EET DST)
X-Scanned: Tue, 13 Jul 2004 21:06:27 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6DI6RAt026380 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 13 Jul 2004 21:06:27 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00G60oCx; Tue, 13 Jul 2004 21:06:26 EEST
Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DI6Pu01339 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 13 Jul 2004 21:06:26 +0300 (EET DST)
Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Jul 2004 13:06:23 -0500
Received: mvebe001 172.18.140.37 from 172.19.66.99 172.19.66.99 via HTTP with MS-WebStorage 6.0.6249
Received: from mvwsipd90027 by mvebe001; 13 Jul 2004 11:06:22 -0700
References: <1089395527.853.66.camel@mvwsipd90027> <Pine.GSO.4.58.0407111309220.5768@irp-view9.cisco.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1.Linox.1)
X-OriginalArrivalTime: 13 Jul 2004 18:06:23.0455 (UTC) FILETIME=[1B7366F0:01C46904]
Message-ID: <1089741982.20287.9.camel@mvwsipd90027>
Date: Tue, 13 Jul 2004 11:06:22 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Suresh Melam <nagavenkata.melam@NOKIA.COM>
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <Pine.GSO.4.58.0407111309220.5768@irp-view9.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Abhay,

I've following two observations.

- While "Instances" are meant to distinguish multiple instances on a
single link, each interface, as mentioned in 2740, will still be
assigned a single Instance ID. Any packets received with instance ID
different than the one in Interface structure will be dropped by the
OSPF. All our IPsec rules/SAs have interface as one of the selector.
Thus these SAs will be tied uniquely to an Instance. We will make
explicit mention of this point in the draft.

- IPsec is meant to provide security at the IP layer and thus most of
the selectors are only IP selectors. Special consideration has been
given to the port numbers of well-known transport protocols like TCP/UDP
and thus they are also included as selectors. The latest IPsec
architecture draft (draft-ietf-ipsec-rfc2401bis-02.txt, Sec 4.4.1.1) has
added few more selectors that are specific to upper layers, but still
hasn't provided any option to specify arbitrary upper layer fields as
IPsec selectors. As we expect the underlying IPsec implementations to be
standard ones, we cannot enforce any additional requirements to the
IPsec implementations.

Thus I would conclude that there are no issues with supporting multiple
OSPF instances on a single link, but distinguishing OSPFv2 and OSPFv3
packets running over same IPv4 family would be not a viable solution.
Please see my followup mail to Vishwas mail for further discussion of
this multiple AF issue.

thanks,
-suresh


On Sun, 2004-07-11 at 13:14, ext Abhay Roy wrote:
> Suresh,
>
> I am afraid, we need to have IPsec selector go deeper. Otherwise
> we can't allow different OSPFv3 Instance ID's to use different
> IPsec security associations (SAs).
>
> I noticed that draft-ietf-ospf-ospfv3-auth doesn't talk about
> possibility of running multiple instance per link, and it's
> interaction / implications with IPSec SAs. We should address that.
>
> Regards,
> -Roy-
>
> On 07/09/04-0700 at 10:52am, Suresh Melam writes:
>
> > Hi Abhay/Vishwas,
> >
> > comments inline,
> >
> > thanks,
> > -suresh (Nagavenkata Suresh Melam)
> >
> >
> > >> Hi Vishwas,
> > >>
> > >> Thanks for the comments.  Please see my comments inline..
> > >>
> > >> > 1. I am not sure we should have a statement which says OSPFv3
> > >> > is only for IPv6.
> > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6,
> > >> > the distinction between the packets can be easily made by
> > >> > IP version. "
> > >>
> > >> Do you have a replacement statement that you would prefer ?
> > >> As the IP protocol type value for OSPF and OSPFv3 is same,
> > >> we have to depend upon the IP version to separate OSPF and
> > >> OSPFv3 packets.
> > >
> > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of
> > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux
> > >will be based on OSPF protocol version.
> > >
> >
> > IPsec selectors are not usually any deeper than protocol field of
> > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF
> > protocol version cannot be one of the selector.
> >
> > If OSPFv3 runs on IPv4 transport, there wouldn't be any way
> > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them
> > use same protocol value. Thus IPsec security, as mentioned in
> > "Security considerations" section of RFC2740 and ospfv3-auth draft,
> > cannot be provided to these packets. Perhaps this should be mentioned
> > in the "Security Considerations" section of ospfv3-af-alt draft.
> >
> > >Regards,
> > >-Roy-
> >