headers
srwg | 1 Oct 2007 15:26
Picon
Favicon

IPSec with IPComp Tunnel Mode


Dear all,
I'm just really using linux for a while. Now I'm trying these and those in
many aspects with linux especially CentOS5 . My problem is 'Is CentOS5's
ipsec-tools (ipsec-tools-0.6.5-8.el5) can config to use IPComp compression
with Tunnel mode?' I use 'setkey -f test.conf' command to set up SAD and SPD
database on my IPv4 channel. At first, I just trying whether I can add the
database like this on one side of end terminal (ip 192.168.0.99)....
test.conf <<EOF
flush;
spdflush;

add 192.168.0.99 192.168.0.218 ipcomp 1000
-m tunnel
-C deflate ;

add 192.168.0.218 192.168.0.99 ipcomp 1001
-m tunnel
-C deflate ;

spdadd 192.168.0.99 192.168.0.218 any
-P out ipsec ipcomp/tunnel/192.168.0.99-192.168.0.218/use ;

spdadd 192.168.0.218 192.168.0.99 any
-P in ipsec ipcomp/tunnel/192.168.0.218-192.168.0.99/use ;
EOF
'setkey -f test.conf' fail at both '-m tunnel' line with 
"The result of line 3: Invalid argument.
The result of line 7: Invalid argument. "
So I wonder above mentioned problem because when I test this on the other
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 1 Oct 2007 23:43
Picon
Favicon

Last Call: draft-lepinski-dh-groups (Additional Diffie-Hellman Groups for use with IETF Standards) to Informational RFC

The IESG has received a request from an individual submitter to consider
the following document:

- 'Additional Diffie-Hellman Groups for use with IETF Standards '
    <draft-lepinski-dh-groups-01.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2007-10-23. Exceptionally,
comments may be sent to iesg <at> ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-lepinski-dh-groups-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16420&rfc_flag=0
Permalink | Reply | 0 comments |
headers
The IESG | 1 Oct 2007 23:43
Picon
Favicon

Last Call: draft-lepinski-dh-groups (Additional Diffie-Hellman Groups for use with IETF Standards) to Informational RFC

The IESG has received a request from an individual submitter to consider
the following document:

- 'Additional Diffie-Hellman Groups for use with IETF Standards '
    <draft-lepinski-dh-groups-01.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2007-10-23. Exceptionally,
comments may be sent to iesg <at> ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-lepinski-dh-groups-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16420&rfc_flag=0
Permalink | Reply | 0 comments |
headers
The IESG | 1 Oct 2007 23:43
Picon
Favicon

Last Call: draft-lepinski-dh-groups (Additional Diffie-Hellman Groups for use with IETF Standards) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:

- 'Additional Diffie-Hellman Groups for use with IETF Standards '
    <draft-lepinski-dh-groups-01.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2007-10-23. Exceptionally,
comments may be sent to iesg <at> ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-lepinski-dh-groups-01.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16420&rfc_flag=0
Permalink | Reply | 0 comments |
headers
Anil Bollineni | 2 Oct 2007 01:26
Favicon

About PFS for first CHILD_SA

Hi there,

I would like to know how PFS is achieved for first CHILD_SA that is created as part of piggyback in AUTH exchange.

 

RFC 4306 says no KE will be exchanged and RFC 4718 says no D-H group is exchanged for first CHILD_SA.

 

Does it mean the first CHILD_SA will inherit all keys from first SA_INIT?

 

If anybody know the answer for this, can you please tell to me?

 

Thanks in Advance,

Anil

 

 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 2 comments |
headers
Black_David | 2 Oct 2007 03:18

RE: About PFS for first CHILD_SA

Anil,

> I would like to know how PFS is achieved for first CHILD_SA that is
> created as part of piggyback in AUTH exchange.

PFS against what?  The IKE SA and the first child SA are created at
essentially the same time.  There isn't anything previous against
which to provide forward secrecy.  

> RFC 4306 says no KE will be exchanged and RFC 4718 says no D-H group
is
> exchanged for first CHILD_SA.

And there are no Nonces for the first CHILD_SA, either.

> Does it mean the first CHILD_SA will inherit all keys from first
SA_INIT?

Not exactly.  See the first part of Section 2.17 of RFC 4306 - the
Ni and Nr inputs are from the SA_INIT, but the SK_d input comes from
the keying material generated for the IKE_SA (see Section 2.14).

So, the keys for the two SAs are separate, but they all depend on the
SKEYSEED master secret (Section 2.14).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
Permalink | Reply | 1 comment |
headers
Joy Latten | 2 Oct 2007 19:49
Picon
Favicon

rfc 4301 and multiple SAs

I would just like some verification about multiple SAs
with same selector values requirement.

It appears establishment and maintenance of multiple SAs
with the same selector values is a MUST in order
to support QoS/DSCP.

If an implementation decides to route all QoS traffic
over the same SA pair, I assumed it would not eliminate 
the need to support multiple SAs with same selectors. 
Because, local implementation must be able to respond to and 
establish SAs with a remote who does want multiple SAs
with same selectors because remote implementation does 
route traffic over several SAs. Right? 

Regards,
Joy Latten
Permalink | Reply | 3 comments |
headers
ns srinivasa murthy | 3 Oct 2007 09:59

Re: rfc 4301 and multiple SAs


You are right.We at Intoto allow creation of
multiple SAs with the same selectors(even if DSCP is not selected).

But the remote implementation (that does route traffic over several SAs)
shall not check DSCP value in the IP Header to find out whether the packet is received on appropritae SA or not.It should allow traffic on any one of the SA's created by the same selectors.It shall be selective of SA's only for outbound traffic.
We at Intoto support this also.

-ns murthy
 Intoto
   
At 11:19 PM 10/2/2007, Joy Latten wrote:
I would just like some verification about multiple SAs
with same selector values requirement.

It appears establishment and maintenance of multiple SAs
with the same selector values is a MUST in order
to support QoS/DSCP.

If an implementation decides to route all QoS traffic
over the same SA pair, I assumed it would not eliminate
the need to support multiple SAs with same selectors.
Because, local implementation must be able to respond to and
establish SAs with a remote who does want multiple SAs
with same selectors because remote implementation does
route traffic over several SAs. Right?

Regards,
Joy Latten


_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
Karen Seo | 3 Oct 2007 16:45
Picon

Re: rfc 4301 and multiple SAs

Hello,

Yes, it's a MUST for the IPsec implementation to support multiple SAs 
with the same selectors for support of QoS.  See sections 4.1 (pages 
13 and 14) and 7.2 (page 68) for further info.

Karen

>I would just like some verification about multiple SAs
>with same selector values requirement.
>
>It appears establishment and maintenance of multiple SAs
>with the same selector values is a MUST in order
>to support QoS/DSCP.
>
>If an implementation decides to route all QoS traffic
>over the same SA pair, I assumed it would not eliminate
>the need to support multiple SAs with same selectors.
>Because, local implementation must be able to respond to and
>establish SAs with a remote who does want multiple SAs
>with same selectors because remote implementation does
>route traffic over several SAs. Right?
>
>Regards,
>Joy Latten
>
>
>_______________________________________________
>IPsec mailing list
>IPsec <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |
headers
rohitvarun | 6 Oct 2007 21:47
Picon

Do we like the same books?

I just joined Shelfari to connect with other book lovers. Come see the books I love and see if we have any in common. Then pick my next book so I can keep on reading.

Click below to join my group of friends on Shelfari!

http://www.shelfari.com/

rohitvarun


Shelfari is a free site that lets you share book ratings and reviews with friends and meet people who have similar tastes in books. It also lets you build an online bookshelf, join book clubs, and get good book recommendations from friends. You should check it out.

You have received this email because rohitvarun (rohit.varun <at> gmail.com) directly invited you to join his/her community on Shelfari.

It is against Shelfari's policies to invite people who you don't know directly. Follow this link to prevent future invitations to this address. If you believe you do not know this person, you may view his/her Shelfari page or report him/her in our feedback section.

Shelfari, 616 1st Ave #300, Seattle, WA 98104 

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 0 comments |

Gmane