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 XAA19825 for ; Tue, 17 May 2005 23:27:56 -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 <0.0104D498@cherry.ease.lsoft.com>; Tue, 17 May 2005 23:27:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 71305002 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 May 2005 23:27:54 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 17 May 2005 23:27:54 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55B59.937E8049" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: More comments and questions on OSPFv3 security draft Thread-Index: AcVbGfXCIK0ZHKApSh6vvoFtmuhrTQAQRcdw Message-ID: Date: Tue, 17 May 2005 20:27:53 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: More comments and questions on OSPFv3 security draft To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C55B59.937E8049 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 The quote I refer to is from 2401bis(which is with the IESG), which replaces 2401. "- Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges of IP addresses (unicast, anycast, broadcast (IPv4 only), or multicast group). " I would be ok if any clarification is added though. =20 Thanks, Vishwas =20 ________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox Sent: Wednesday, May 18, 2005 1:22 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: More comments and questions on OSPFv3 security draft =20 Back in Feburary and March I had a dialog with Vishwas involving some questions on the OSPFv3 security draft. Our security expert has asked for some additional clarification, here is his comment: =20 My comment is based on the following from RFC 2401 (section 4.1):=20 A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well.=20 As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. Comment: Certainly an SPD can have a ranged address that points to the same SA. This is how you would set up an SPD in a firewall for tunnel mode traffic. That is, a range of addresses for a network (not on the firewall) can use a single SA. The destination IP address is an IPSec SA endpoint. However, the SA must adhere to the definition above. For unicast transport mode, I read this to be that the destination address is a single IP address not a range. I suggest that the OSPFv3 security draft specify exactly how the manual SAs would need to be set up to be compliant. I don't think there is anything in RFC 2401 that allows a range of unicast IP addresses to be "a unicast address".=20 And since it has been a while, here is the string of notes he is commenting on:=20 =20 Vishwas Manral =20 Sent by: Mailing List =20 03/01/2005 05:59 AM=20 Please respond to Mailing List=20 =20 To: OSPF@PEACH.EASE.LSOFT.COM=20 cc: =20 Subject: Re: Questions about OSPF v3 security draft Hi Mike, Sorry for the delay. I may be wrong as I have not implemented this myself, however my views are as follows: - If you see the SPD entry the Remote IP Address can be=20 "- Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges of IP addresses (unicast, anycast, broadcast (IPv4 only), or multicast group). " So for OSPF the Multicast as well as the unicast addresses will be used to refer to an SA. Next Layer Protocol would say OSPF. That way we will have just one entry for all OSPF packets out of an interface, just as we want it and a similar entry for inbound traffic. I do not see a case of Full Mesh at all. I may be missing the point. Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox Sent: Friday, February 25, 2005 2:58 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Questions about OSPF v3 security draft Vishwas,=20 I shared your response with our security expert and here is his response:=20 What we need to know is whether the paragraph is referring to unicast. " What it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface." If this comment is referring to unicast, the point remains is that there will be multiple SAs. We will not be able to adhere to the figure 3 requirements for unicast, and there will be full meshing of SAs required between all communicating OSPFs. Not so bad if using IKE. Really bad if using manual SAs. =20 Here is the thread of notes being referred to (since it's been a couple of weeks):=20 Vishwas Manral =20 Sent by: Mailing List =20 02/15/2005 12:01 AM=20 Please respond to Mailing List=20 =20 To: OSPF@PEACH.EASE.LSOFT.COM=20 cc: =20 Subject: Re: Questions about OSPF v3 security draft Hi Mike,=20 =20 I think both the authors are on leave, so they will probably reply later.=20 =20 However regarding the first point, I agree the wording should be clearer. However what it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an interface.=20 =20 Regarding the second point, I think I too have brought the issue on this list and the reply I think was that the draft does not prohibit the use of IKE for unicast flows.=20 =20 Thanks,=20 Vishwas=20 ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox Sent: Friday, February 11, 2005 8:04 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Questions about OSPF v3 security draft=20 =20 Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, and the previous drafts, a couple of questions have come up in our shop. 1) Section 7, 2nd paragraph says "the implementations MUST use manually configured keys with same SA for inbound and outbound traffic (as shown in figure 3). I assume the "same SA" MUST rule applies to multicast traffic only and not unicast traffic. This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP address. For unicast addresses, by definition there will be as many SAs as there are unicast destination addresses. Therefore, I don't think it is possible to apply this MUST rule given the current IPSec definition (RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of the draft was to apply only to multicast and given the number of potential SAs carrying unicast traffic, it would seem that using IKE to setup the SAs dynamically would be a reasonable alternative to manual keying. =20 =20 2)Section 9, 2nd paragraph discusses setting up a "secure IPSec channel dynamically once it acquires the required information". Since this traffic is unicast only, IKE could easily set up the required SAs without knowing the specific IP addresses in advance. Creating SAs dynamically do not fit easily within scope of manual SA functional capabilities. Why not use IKE for this traffic? Is this an acceptable option? =20 Mike=20 ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA ------_=_NextPart_001_01C55B59.937E8049 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Mike,

 

The quote I refer to is from = 2401bis(which is with the IESG), which replaces 2401.

     "- Remote IP Address(es) (IPv4 or = IPv6): this is a list of ranges
       of IP = addresses (unicast, anycast, broadcast (IPv4 only), or
       multicast = group). "

I would be ok if any clarification is added = though.

 

Thanks,

=

Vishwas

=

 

From: = Mailing List = [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox
Sent: Wednesday, May 18, = 2005 1:22 AM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: More comments = and questions on OSPFv3 security draft

 


Back in Feburary and March I had a dialog with = Vishwas involving some questions on the OSPFv3 security draft.  Our = security expert has asked for some additional clarification, here is his comment: =  

My comment is based on the following from RFC 2401 (section 4.1): =

A security association is uniquely identified by a = triple consisting
  of a Security Parameter Index = (SPI), an IP Destination Address, and a
  security protocol (AH or ESP) = identifier.  In = principle, the
  Destination Address may be = a unicast address, an IP = broadcast
  address, or a multicast group = address.  However, IPsec SA management
  mechanisms currently are defined = only for unicast SAs.  Hence, in the
  discussions that follow, SAs will = be described in the context of
  point-to-point communication, even = though the concept is applicable
  in the point-to-multipoint case as = well.

As noted above, two types of SAs are defined: transport mode = and
  tunnel mode.  A transport = mode SA is a security association between
  two hosts.

Comment: Certainly an SPD can have a ranged address that points to the same SA. This is how = you would set up an SPD in a firewall for tunnel mode traffic. That is, a = range of addresses for a network (not on the firewall) can use a single SA. The = destination IP address is an IPSec SA endpoint. However, the SA must adhere to the definition above. For unicast transport mode, I read this to be that the destination address is a single IP address not a range. I suggest that = the OSPFv3 security draft specify exactly how the manual SAs would need to = be set up to be compliant. I don't think there is anything in RFC 2401 that = allows a range of unicast IP addresses to be "a unicast address". =

And since it has been a while, here is the string of notes he is commenting = on:



 

Vishwas= Manral <Vishwas@SINETT.COM>
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>

03/01/2005 05:59 AM
Please respond to Mailing = List

       
        To:       =  OSPF@PEACH.EASE.LSOFT.COM
        cc:         =
        Subject:        Re: Questions = about OSPF v3 security draft




Hi Mike,

Sorry for the delay. I may be wrong as I = have not implemented this myself, however my views are as follows: = -

If you see the SPD entry the Remote IP = Address can be
     "- Remote IP = Address(es) (IPv4 or IPv6): this is a list of ranges
       of IP = addresses (unicast, anycast, broadcast (IPv4 only), or
            =    multicast group). "
So for OSPF the Multicast as well as the = unicast addresses will be used to refer to an SA.

Next Layer Protocol would say = OSPF.

That way we will have just one entry for = all OSPF packets out of an interface, just as we want it and a similar entry for = inbound traffic. I do not see a case of Full Mesh at all. I may be missing the = point.

Thanks,
Vishwas
________________________________________
From: Mailing = List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox
Sent: Friday, February 25, 2005 2:58 = AM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Questions about OSPF v3 = security draft


Vishwas,

I shared your response with our security = expert and here is his response:

What we need to know is whether the = paragraph is referring to unicast. " What it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an = interface." If this comment is referring to unicast, the point remains is that there = will be multiple SAs. We will not be able to adhere to the figure 3 = requirements for unicast, and there will be full meshing of SAs required between all communicating OSPFs. Not so bad if using IKE. Really bad if using manual = SAs.  

Here is the thread of notes being = referred to (since it's been a couple of weeks):

Vishwas = Manral <Vishwas@SINETT.COM>
Sent by: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
02/15/2005 12:01 AM
Please respond to Mailing List
        =
        To:   =      OSPF@PEACH.EASE.LSOFT.COM
        cc:   =      
        Subject: =        Re: Questions about OSPF v3 security draft



Hi Mike,
 
I think both the authors are on leave, so = they will probably reply later.
 
However regarding the first point, I = agree the wording should be clearer. However what it means is we will use the same crypto-algorithm and keys for all traffic to a neighbor over an = interface.
 
Regarding the second point, I think I too = have brought the issue on this list and the reply I think was that the draft = does not prohibit the use of IKE for unicast flows.
            =                       =                       =                       =                       =                       =                       =          
Thanks,
Vishwas
________________________________________

From: Mailing = List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mike Fox
Sent: Friday, February 11, 2005 8:04 = PM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Questions about OSPF v3 security = draft
 

Regarding http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-07.txt, = and the previous drafts, a couple of questions have come up in our shop. =

1) Section 7, 2nd paragraph says = "the implementations MUST use manually configured keys with same SA for = inbound and outbound traffic (as shown in figure 3).  I assume the "same = SA" MUST rule applies to multicast traffic only and not unicast traffic. = This is because an SA is defined as an SPI, security protocol (AH or ESP), and destination IP address. For unicast addresses, by definition there will = be as many SAs as there are unicast destination addresses. Therefore, I don't = think it is possible to apply this MUST rule given the current IPSec = definition (RFC 2401 section 4.1) of an SA for unicast. Assuming the intention of the = draft was to apply only to multicast and given the number of potential SAs = carrying unicast traffic, it would seem that using IKE to setup the SAs = dynamically would be a reasonable alternative to manual keying.     =
 
2)Section 9, 2nd paragraph discusses = setting up a "secure IPSec channel dynamically once it acquires the required information".  Since this traffic is unicast only, IKE could = easily set up the required SAs without knowing the specific IP addresses in = advance. Creating SAs dynamically do not fit easily within scope of manual SA = functional capabilities. Why not use IKE for this traffic? Is this an acceptable = option?  

Mike


----------------------------------------------------------------------- Enterprise Network Solutions
----------------------------------------------------------------------- Research Triangle = Park, NC  USA=

------_=_NextPart_001_01C55B59.937E8049--