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

[Abhay Roy <[e-mail]>]

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