Grubmair Peter | 1 Jul 16:00 2004
Picon

Opaque and any in selectors of RFC2401bis 14

On page 21, 4.4.1 it is stated, that for SPD
ANY includes OPAQUE.
On Page 34 of 4.4.2 for SAD, it seems to me
that ANY does not include OPAQUE as
e.g
protocols has two ports
                                      Value in
                                      Triggering   Resulting SAD
       Selector  SPD Entry        PFP Packet       Entry
       --------  ---------------- --- ------------ --------------
      loc port    list of ranges    0  no src port  discard packet
                     or ANY

                 OPAQUE             0  not avail.   OPAQUE

does this mean that for generation of SAD selector from SPD selector now ANY
does not include OPAQUE ?

or should the table be modified the following way ?

                                      Value in
                                      Triggering   Resulting SAD
       Selector  SPD Entry        PFP Packet       Entry
       --------  ---------------- --- ------------ --------------
      loc port    list of ranges    0  no src port  discard packet

                  ANY               0  no src port  OPAQUE

                 OPAQUE             0  not avail.   OPAQUE

(Continue reading)

wprice | 2 Jul 08:05 2004
Picon

stolen

information about you

VIRUS INFECTION ALERT

The Gauntlet Firewall&reg discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: concert.zip
Virus name: W32/Netsky.b <at> MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

_______________________________________________
Ipsec mailing list
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Stephen Kent | 2 Jul 16:15 2004
Picon

RE: Layer 2 processing inside IPsec

At 8:10 PM +0200 6/30/04, Francois.PAUL <at> fr.thalesgroup.com wrote:
>I summarize hereafter the main points that arise from the different messages
>posted to this list :
>   - Combining ROHC (or whichever generic compression frameworks suits) and
>IPsec in an efficient way leads to an integration of ROHC in the middle of
>IPsec. From the IPsec framework point of view, this could take the form ESP
>used in tunnel mode, but with a specific "next header" value different from
>"IP", in order for the policy enforcement processing to take place just
>after decryption and decompression, along the lines of what Jan Vilhuber
>proposed.

tunnel mode requires that the next header be IP (v4 or v6) because 
that header is used for the access control checks. So I don't 
understand your description above.

Steve
Francois.PAUL | 2 Jul 18:26 2004

RE: Layer 2 processing inside IPsec

This is the reason why it is proposed to insert decompression *between*
decryption and policy enforcement. Once the encrypted payload is decrypted,
if the "next header" field shows that it is a ROHC-compressed packet, the
appropriate decompressor is applied, which produces a regular IPv4 or IPv6
packet header. Then, the classical IPsec access control checks are applied.

This is described in details in Jan Vilhuber's proposal, though the present
draft invokes compression schemes (not so) different from ROHC.

F. Paul

-----Message d'origine-----
De : Stephen Kent [mailto:kent <at> bbn.com]
Envoye : vendredi 2 juillet 2004 16:15
A : Francois.PAUL <at> fr.thalesgroup.com
Cc : Francis.Dupont <at> enst-bretagne.fr; sommerfeld <at> east.sun.com;
ipsec <at> ietf.org
Objet : RE: [Ipsec] Layer 2 processing inside IPsec

At 8:10 PM +0200 6/30/04, Francois.PAUL <at> fr.thalesgroup.com wrote:
>I summarize hereafter the main points that arise from the different
messages
>posted to this list :
>   - Combining ROHC (or whichever generic compression frameworks suits) and
>IPsec in an efficient way leads to an integration of ROHC in the middle of
>IPsec. From the IPsec framework point of view, this could take the form ESP
>used in tunnel mode, but with a specific "next header" value different from
>"IP", in order for the policy enforcement processing to take place just
>after decryption and decompression, along the lines of what Jan Vilhuber
>proposed.
(Continue reading)

Stephen Kent | 2 Jul 19:41 2004
Picon

RE: Layer 2 processing inside IPsec

At 6:26 PM +0200 7/2/04, Francois.PAUL <at> fr.thalesgroup.com wrote:
>This is the reason why it is proposed to insert decompression *between*
>decryption and policy enforcement. Once the encrypted payload is decrypted,
>if the "next header" field shows that it is a ROHC-compressed packet, the
>appropriate decompressor is applied, which produces a regular IPv4 or IPv6
>packet header. Then, the classical IPsec access control checks are applied.
>
>This is described in details in Jan Vilhuber's proposal, though the present
>draft invokes compression schemes (not so) different from ROHC.
>
>F. Paul
>

Thanks for the clarification. it was just the choice of words that 
made it confusing to me.  Look at the new processing model in 
2401bis, and see how you would describe the processing in that 
context, to make sure this is consistent with that model.

Steve
Stephen Kent | 2 Jul 19:52 2004
Picon

RE: Layer 2 processing inside IPsec

At 10:33 AM -0700 7/2/04, Paul Lambert wrote:
>  >tunnel mode requires that the next header be IP (v4 or v6)
>
>Requireing the next header to be IP is just one type of access 
>policy.  There is no reason that an access policy could not allow 
>other protocols and process/filter them accordingly.
>
>Paul
>
>-

There is a requirement for an IPsec TUNNEL to have an inner IP 
header, because of the need to forward the inner packet based on that 
header, and because our access control checks are defined relative to 
IP and next layer headers. if there is no need to forward the packet 
based on an inner IP header, then transport mode is used, and the 
access controls are applied to the outer header.

Steeve
Bob Arthurs | 3 Jul 19:34 2004
Picon

RFC 3715 / IPsec NAT Compatibility

Hi Folks,

Quick question about RFC 3715 - on page 4 (c) the RFC mentions 
incompatibility between IKE address identifiers and NAT.

Would I be right in saying that this incompatibility occurs only in 
transport mode when using IP addresses as phase 1 identifiers, and when the 
source address of ISAKMP packets is checked against the traffic selectors 
carried as identifiers in phase 2 ?? Or have I completely missed the point 
:)

Many thanks in advance.

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo
Scott | 4 Jul 16:41 2004

Notification


VIRUS INFECTION ALERT

The Gauntlet Firewall&reg discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: the_message.com
Virus name: W32/Bagle.aa <at> MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

_______________________________________________
Ipsec mailing list
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Kivinen | 5 Jul 17:35 2004
Picon
Picon

RE: Text message


VIRUS INFECTION ALERT

The Gauntlet Firewall&reg discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Alive_condom.vbs
Virus name: W32/Bagle.aa <at> MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

_______________________________________________
Ipsec mailing list
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Kivinen | 6 Jul 11:39 2004
Picon
Picon

Re: Yahoo!


VIRUS INFECTION ALERT

The Gauntlet Firewall&reg discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Document.exe
Virus name: W32/Bagle.aa <at> MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

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

Gmane