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

stolen

information about you

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

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

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.

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

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

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

Notification

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

RE: Text message

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

Re: Yahoo!

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