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

Suresh Melam <nagavenkata.melam@NOKIA.COM> Tue, 13 July 2004 19:05 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 PAA04383 for <ospf-archive@LISTS.IETF.ORG>; Tue, 13 Jul 2004 15:05:21 -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 <2.00E14370@cherry.ease.lsoft.com>; Tue, 13 Jul 2004 15:05:11 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25777635 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Jul 2004 15:05:10 -0400
Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 13 Jul 2004 15:05:09 -0400
Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DJ57b23276 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 13 Jul 2004 22:05:08 +0300 (EET DST)
X-Scanned: Tue, 13 Jul 2004 22:04:41 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE
Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i6DJ4fdw013727 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 13 Jul 2004 22:04:41 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 001k3v7Z; Tue, 13 Jul 2004 22:04:39 EEST
Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6DJ4bn00987 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 13 Jul 2004 22:04:38 +0300 (EET DST)
Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 13 Jul 2004 14:04:21 -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 12:04:19 -0700
References: <BB6D74C75CC76A419B6D6FA7C38317B22E829D@sinett-sbs.SiNett.LAN>
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 19:04:21.0035 (UTC) FILETIME=[343FFFB0:01C4690C]
Message-ID: <1089745459.20287.68.camel@mvwsipd90027>
Date: Tue, 13 Jul 2004 12:04:19 -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: <BB6D74C75CC76A419B6D6FA7C38317B22E829D@sinett-sbs.SiNett.LAN>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Vishwas,

comments inline,

thanks,
-suresh


On Sat, 2004-07-10 at 01:00, Vishwas Manral wrote:
> Hi Suresh,
>
> I was thinking the following assumptions would hold good: -
>
> 1. We either run OSPFv3 for IPv4 or OSPFv2 for IPv4 not both.
> 2. While configuring the SA(we dont use IKE), both ends agree to the protocol they are using.
>
> Wouldn't it help in that case? I think the AF draft should state the limitation instead.

Yes, in this case of running only one of OSPFv3 or OSPFv2 over IPv4 AF,
but not both, it should be possible to use same rules as those we
suggest in our draft to secure the IPv4 OSPF traffic. Only difference is
that we should use equivalent IPv4 addresses for instead of IPv6
addresses. For eg., IPv6 multicast OSPF address should be replaced with
IPv4 multicast OSPF address and so on. While we try to make sure that
any rule in our draft will not conflict with the requirement of running
OSPFv3 traffic over IPv4 traffic, we too believe that AF draft should
make a clear mention of how IPsec can be used in a such a case.

>
> Suresh, also if the link is assumed to be point-to-point would we still restrict to the use of static configuration and not IKE.

Yes, we suggest to use manual keying in all cases just to have a simple
configuration. IKE might involve PKI too. If manual keying is considered
secure enough for other types of links, we believe it should be secure
enough for point-to-point links too. If there is any strong reason why
IKE should be used over point-to-point link, the two end points are
welcome to use IKE and it would be specific to only those two endpoints.



>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Suresh
> Melam
> Sent: Friday, July 09, 2004 11:22 PM
> To: OSPF@PEACH.EASE.LSOFT.COM
> Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
>
>
> 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-