Subject: [Ipsec] RE: Ipsec Digest, Vol 7, Issue 34

From: "Phan, Thang" <[email-masked]>
Date: Tue, 30 Nov 2004 15:18:36 -0500

I think you have a nice crack ;)
Let me count it - one. 

Thang Phan
Network Analyst
[email-masked]
1000 Bent Creek Blvd., Suite 200
Mechanicsburg, PA  17050
717.790.8137 (P)
717.790.8170 (F)
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, November 30, 2004 12:26 PM
To: [email-masked]
Subject: Ipsec Digest, Vol 7, Issue 34

Send Ipsec mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ipsec
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Ipsec digest..."

Today's Topics:

   1. Re: Why Destionation address while SPI is present. (Joe Touch)
   2. Co-existence of IPsec implementations (was: Re: [Ipsec] Why
      Destionation address while SPI is present) (William Dixon)
   3. Re: Why Destionation address while SPI is present. (Stephen Kent)
   4. Re: Why Destionation address while SPI is present. (Joe Touch)
   5. About case A and Case B? (mahdavi)

----------------------------------------------------------------------

Message: 1
Date: Mon, 29 Nov 2004 17:10:20 -0800
From: Joe Touch <[email-masked]>
Subject: Re: [Ipsec] Why Destionation address while SPI is present.
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

One issue for unique SPIs is coordination of different BITW instances on
a single machine. Presumably they have different IP addresses, but
omitting that address from the lookup means the different BITWs would be
_required_ to coordinate SPIs issued.

I.e., does omitting the address put additional constraints on BITWs?

Joe

Stephen Kent wrote:
| At 2:26 PM +0330 11/27/04, mahdavi wrote:
|
|> Hi.
|>
|> I have confused with this sentence in RFC2401
|>
|> "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."
|>
|>
|> Since SPI is generated by the receiver, Receiver can generate a 
|> unique SPI for himself. In Inbound receiver can just search on SPI 
|> and does not need to seaech on IP Destination Address and security 
|> protocol too.
|>
|> So Y we should search on these two fields too ? ?
|>
|> PS: we are designing IPSec in heart of a high speed router.
|>
|> thanks in advance.
|>
|
| Yes, the use of an address is redundant for IPsec unicast traffic, and

| unless the receiver chooses to reuse the SPI space for AH and ESP, it 
| there is no need to examine the protocol field either. In 2401bis we 
| have reworded this section.
|
| Steve
|
| _______________________________________________
| Ipsec mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/ipsec

------------------------------

Message: 2
Date: Tue, 30 Nov 2004 03:10:25 -0800
From: "William Dixon" <[email-masked]>
Subject: Co-existence of IPsec implementations (was: Re: [Ipsec] Why
	Destionation address while SPI is present)
To: "'Joe Touch'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

I've always thought that 2401 & 2401bis assumed there was one IPsec
implementation for a given IP address in theory. Maybe that's not
strictly required, but then neither is support for two or more in
coexistence specifically required. A number of conflicts could occur if
more than one IPsec implementation uses the same IP address, in addition
to SPI selection.

They both will be blocking, permitting and negotiating SAs for
potentially the same traffic with different policies that are
potentially independently administered. It would be difficult to have
multiple IKEs listening on port 500. But easy enough to configure IKE to
use different ports with policy.
You'd have to be able to not drop a packet with a SPI that wasn't yours.
And be able to guarantee binding order for packet intercept during
successive boots.

Coexistence has been a practical market requirement for client host
platforms given the popularity of IPsec tunnel VPN clients.

I can imagine that there will be varying degrees of native support for
IPsec-based scenarios for IPv6, just as we saw for IPv4 remote access.

So my question is whether coexistence should be addressed by a WG
document ?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Joe Touch
> Sent: Monday, November 29, 2004 5:10 PM
> To: Stephen Kent
> Cc: [email-masked]
> Subject: Re: [Ipsec] Why Destionation address while SPI is present.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> One issue for unique SPIs is coordination of different BITW instances 
> on a single machine. Presumably they have different IP addresses, but 
> omitting that address from the lookup means the different BITWs would 
> be _required_ to coordinate SPIs issued.
> 
> I.e., does omitting the address put additional constraints on BITWs?
> 
> Joe
>

------------------------------

Message: 3
Date: Tue, 30 Nov 2004 09:33:56 -0500
From: Stephen Kent <[email-masked]>
Subject: Re: [Ipsec] Why Destionation address while SPI is present.
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Message-ID: <p06200700bdd233a15f1f@[128.89.89.75]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 5:10 PM -0800 11/29/04, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>One issue for unique SPIs is coordination of different BITW instances 
>on a single machine. Presumably they have different IP addresses, but 
>omitting that address from the lookup means the different BITWs would 
>be _required_ to coordinate SPIs issued.
>
>I.e., does omitting the address put additional constraints on BITWs?
>
>Joe
>

Joe,

Each BITW device is an independent implementation of IPsec, so I would
not expect them to be able to coordinate SPI generation, nor would I
expect them to be able to share keys. if they don't share keys, then
traffic arriving at the "wrong" one cannot be processed anyway. So, I
would rely on each having a different address and thus not coordinating
any of the other parameters needed to appear to be equivalent. of
course, a vendor may choose to do something outside of the spec to offer
this sort of extended functionality, but the key sharing issue might
make it harder to achieve FIPS 140-2 approval.

Steve

------------------------------

Message: 4
Date: Tue, 30 Nov 2004 07:35:41 -0800
From: Joe Touch <[email-masked]>
Subject: Re: [Ipsec] Why Destionation address while SPI is present.
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Stephen Kent wrote:
> At 5:10 PM -0800 11/29/04, Joe Touch wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> One issue for unique SPIs is coordination of different BITW instances

>> on a single machine. Presumably they have different IP addresses, but

>> omitting that address from the lookup means the different BITWs would

>> be _required_ to coordinate SPIs issued.
>>
>> I.e., does omitting the address put additional constraints on BITWs?
>>
>> Joe
>>
> 
> Joe,
> 
> Each BITW device is an independent implementation of IPsec, so I would

> not expect them to be able to coordinate SPI generation, nor would I 
> expect them to be able to share keys. if they don't share keys, then 
> traffic arriving at the "wrong" one cannot be processed anyway. So, I 
> would rely on each having a different address and thus not 
> coordinating any of the other parameters needed to appear to be 
> equivalent. of course, a vendor may choose to do something outside of 
> the spec to offer this sort of extended functionality, but the key 
> sharing issue might make it harder to achieve FIPS 140-2 approval.
> 
> Steve

Right - that's what I thought. However, that also means that it would be
the address/SPI pair that would be important. I.e., there are two
different kinds of failure:
	a) failed to lookup addr/SPI
	b) key found failed to work

*IF* IPsec considers those different errors, then the pair is required. 
If they're considered equivalent (logged the same, generate/don't
generate the same internal error, etc.), then addr can be omitted.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url :
http://www1.ietf.org/pipermail/ipsec/attachments/20041130/a60a32f5/signa
ture.bin

------------------------------

Message: 5
Date: Tue, 30 Nov 2004 20:15:40 +0330
From: "mahdavi" <[email-masked]>
Subject: [Ipsec] About case A and Case B?
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset=utf-8

I am working on a high speed secure router and there is  something that
I cant Understand what to do with it. 

and that is these mysterious sentences. (I call these as Case A and Case
B )

 "  a. use the value in the packet itself -- This will limit use
       of the SA to those packets which have this packet's value
       for the selector even if the selector for the policy entry
       has a range of allowed values or a wildcard for this
       selector.
    b. use the value associated with the policy entry -- If this
       were to be just a single value, then there would be no
       difference between (b) and (a).,......"

Imagine a router that is IPSec aware (SG1). 

HOST                                                     HOST
C to K=========|1| SG1 |2|=======================SG2 --- M to X
  |               / \                            /           
  |              /   \                          /            
  \-------------/     \------------------------/          

SG1 has two interfaces 1 and 2 . 

outbound policy for interface 2 of SG1 says :

--------------------------------------------------------
For any packet from host (C to k) going to host (M to X) 
make a tunnel with SG2. USE CASE B 
--------------------------------------------------------

This means to use one SA for all traffic traversing from (C - K) TO ( M
- X ).
Right? 

What about this policy? 

--------------------------------------------------------
For any packet from host (C to k) going to host (M to X) 
make a tunnel with SG2. USE CASE A 
--------------------------------------------------------

What that means? Does it mean to make separate SA's for any
source-destination
pair ?
For example one for a packet traversing from C to M and one another for
a
packet giong from D to N and one another for a packet going from C to N
???

If so what is benefit of this ??? 
__________________________________________________________
__________________________________________________________
Question 2: 

Before, I thought that Case A Is not usable in this situation and 
this situation should be used with case b. Was Right ? 

__________________________________________________________
__________________________________________________________
Question 3: 

Can we have such a policy like below for inbound traffic for interface 1
of SG1?

For inbound traffic for interface 1 of SG1 : (this is just one policy
record)

--------------------------------------------------------
For any packet from host (C to k) going to host (M to X) 
make a tunnel with ITSELF (SOURCE OF Packet). 
--------------------------------------------------------

In above policy because we wanted to have one policy for many tunnels 
(in this case 9 tunnels each for each host C - K ) and ITSELF means
having a
tunnel with source of packet host. 

Firstly, having such a policy is logical??? 
Secondly, does it mean Case A??? 

____________________________________________________________

Best of regards 
Mahdavi. 

------------------------------

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

End of Ipsec Digest, Vol 7, Issue 34
************************************

***********************************************************************
This message is intended only for the use of the intended recipient and
may contain information that is PRIVILEGED and/or CONFIDENTIAL.  If you
are not the intended recipient, you are hereby notified that any use,
dissemination, disclosure or copying of this communication is strictly
prohibited.  If you have received this communication in error, please
destroy all copies of this message and its attachments and notify us
immediately.
***********************************************************************

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec