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

[Vishwas Manral <[e-mail]>]

Hi Abhay/Suresh,

Would it help to have different MCast Address for OSPFv2/OSPFv3 over IPv4?

Thanks,
Vishwas

-----Original Message-----
From: Mailing List [mailto:[e-mail]]On Behalf Of Suresh
Melam
Sent: Tuesday, July 13, 2004 11:36 PM
To: [e-mail]
Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt


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