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

Abhay Roy <akr@CISCO.COM> Sun, 11 July 2004 20:14 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 QAA10609 for <ospf-archive@LISTS.IETF.ORG>; Sun, 11 Jul 2004 16:14:10 -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 <8.00E101B1@cherry.ease.lsoft.com>; 11 Jul 2004 16:14:10 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 25438446 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 11 Jul 2004 16:14:09 -0400
Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 11 Jul 2004 16:14:08 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Jul 2004 13:15:21 +0000
X-BrightmailFiltered: true
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6BKE5t3009873 for <OSPF@PEACH.EASE.LSOFT.COM>; Sun, 11 Jul 2004 13:14:06 -0700 (PDT)
Received: from irp-view9.cisco.com (irp-view9.cisco.com [171.70.65.147]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AVG27925; Sun, 11 Jul 2004 13:12:54 -0700 (PDT)
References: <1089395527.853.66.camel@mvwsipd90027>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.GSO.4.58.0407111309220.5768@irp-view9.cisco.com>
Date: Sun, 11 Jul 2004 13:14:05 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Abhay Roy <akr@CISCO.COM>
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <1089395527.853.66.camel@mvwsipd90027>
Precedence: list

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