Re: revised IPsec Architecture draft (2401bis)

 In your previous mail you wrote:

   the source address, for the sender, is trivial if you have just one 
   interface, and if you are  not mobile. if you have multiple 
   interfaces, you do need to specify the right one to use as the source 
   address, statically.
   if you are mobile, you need to have something outside of IPsec
   updating the value,

=> an IPsec/mobile integrate code needs to know the place of the value
to be enabled to update it: I raised the issue exactly for this reason...

   which says that there would not 
   be any useful SPD entry to specify in advance. so, yes, we will add 
   text to accommodate both source and destination addresses for tunnel 
   headers.

=> so this issue is closed.

   >=> when? This is not clear that the SPD is decorrelated... I am afraid
   >the decorrelation goal is to focused on caching so I missed in 5:

   we do not explain how to perform decorrelation in detail the text, 
   but rather refer to Appendix B. A fundamental requirement for any 
   algorithm of this sort is that it breaks overlapping entries into 
   non-overlapping entries. I think the text inn 4.4.1 says that 
   reasonably well.

=> I have no problem with the decorrelation idea (I began with pattern
matching and term rewriting systems where the problem is hard, BTW

Re: Minor typographical errors in draft-ietf-ipsec-rfc2401bis-03.txt

Thank you.

>While going through the rfc2401bis-03 draft, I found the following
>minor typo's.
>
>						- Ted
>
>Page 12, Section 4.1:  Extra curly brace:
>
>       1. Search the SAD for a match on the combination of SPI,
>          destination address, and source address}. If an SAD entry
>          matches, then process the inbound ESP packet with that
>
>If you're removing the curly brace syntax and replacing it with
>explantory text, then you should probably also make the change from
>{SPI} to SPI here:
>
>       3. Search the SAD for a match on only {SPI} if the receiver has
>          chosen to maintain a single SPI space for AH and ESP, and on
>          both SPI  and protocol otherwise. If an SAD entry matches then
>          process the inbound ESP packet with that matching SAD entry.
>          Otherwise, discard the packet and log an auditable event.
>
>--------------------------------
>Page 13:
>
>Extra hyphen in "-support"?
>
>    Therefore a sender SHOULD put traffic of different classes, but with
>    the same selector values, on different SAs to -support QoS

Re: Re: [Ipsec] big IKE packets

* Michael Richardson:

>>>>>> "Paul" == Paul Koning <pkoning <at> equallogic.com> writes:
>     Michael> We could have an option to run over TCP.  But, consider if
>     Michael> one is doing IPsec in the first place to protect TCP
>     Michael> management sessions. Ooops.
>
>     Paul> So?  That's no more an issue than it is for UDP.  A TCP IKE
>     Paul> session would not go through IPsec, just like port 500
>     Paul> UDPgrams don't use IPsec.
>
>   But, they would be vulnerable to the TCP RST attacks that we might in 
> fact trying to defend against in the first place.

Only if you drop state automatically when the TCP session goes down.
You can easily avoid that if you want to.

Re: revised IPsec Architecture draft (2401bis)

Francis,

>=> I have no problem with the decorrelation idea (I began with pattern
>matching and term rewriting systems where the problem is hard, BTW
>IMHO decorrelation is related to completion, i.e., Knuth-Bendix algorithm).
>  But I still believe a statement explaining the SPD is considered as
>being decorrelated after the end of 4.4.1 should be fine.
>
>    >=> so the SAD check works for the first example but not (yet) for the
>    >second where the rule 2 is added* after the creation of the SAD entry
>    >for the rule 1 (*: after in time, before in order).
>   
>    section 4.4.1 concludes with a brief section:
>   
>   	Handling Changes to the SPD while the System is Running
>   
>   	If a change is made to the SPD while the system is running, a check
>   	SHOULD be made of the effect of this change on extant SAs. An
>   	implementation MAY choose to check the impact of an SPD change on
>   	extant SAs and to provide a user/administrator with a mechanism for
>   	configuring what actions to take, e.g., delete an affected SA, allow
>   	an affected SA to continue unchanged, etc.
>   
>    i think this addressed your concern.
>   
>=> yes but this conflicts with the end of 4.4.2:
>
>    For each of the selectors defined in Section 4.4.1.1, the entry for
>    an inbound SA in the SAD MUST contain the value or values negotiated
>    at the time the SA was created. For a receiver, these values are used

Re: revised IPsec Architecture draft (2401bis)

 In your previous mail you wrote:

   >    section 4.4.1 concludes with a brief section:
   >   
   >   	Handling Changes to the SPD while the System is Running
   >   
   >   	If a change is made to the SPD while the system is running, a check
   >   	SHOULD be made of the effect of this change on extant SAs. An
   >   	implementation MAY choose to check the impact of an SPD change on
   >   	extant SAs and to provide a user/administrator with a mechanism for
   >   	configuring what actions to take, e.g., delete an affected SA, allow
   >   	an affected SA to continue unchanged, etc.
   >   
   >    i think this addressed your concern.
   >   
   >=> yes but this conflicts with the end of 4.4.2:
   >
   >    For each of the selectors defined in Section 4.4.1.1, the entry for
   >    an inbound SA in the SAD MUST contain the value or values negotiated
   >    at the time the SA was created. For a receiver, these values are used
   >    to check that the header fields of an inbound packet (after IPsec
   >    processing) match the selector values negotiated for the SA. For the
   >    receiver, this is part of verifying that a packet arriving on an SA
   >    is consistent with the policy for the SA. (See Section 6 for rules
   >    for ICMP messages.)  These fields can have the form of specific
   >    values, ranges, ANY, or OPAQUE, as described in section 4.4.1.1,
   >    "Selectors."
   >
   >(note I like the idea of explaining that the SAD selectors are in fact
   >the inbound SPD cache!)

FYI - RFC3884 and some notes on 2401bis

FYI, the following RFC has (finally) been issued. (it might be useful to 
cite it in sec 4.1  <at> end pg 12/beg pg 13, sec 13 top pg 62, & end sec D.3 
of RFC2401bis, e.g.):

3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L.
      Eggert, Y. Wang. September 2004. (Format: TXT=59437 bytes) (Status:
      INFORMATIONAL)

Joe

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

Re: revised IPsec Architecture draft (2401bis)

 Steve,

I just had one minor comment about the decorrelation part below.
> 
> >=> I have no problem with the decorrelation idea (I began with pattern
> >matching and term rewriting systems where the problem is hard, BTW
> >IMHO decorrelation is related to completion, i.e., Knuth-Bendix algorithm).
> >  But I still believe a statement explaining the SPD is considered as
> >being decorrelated after the end of 4.4.1 should be fine.
> >
> >    >=> so the SAD check works for the first example but not (yet) for the
> >    >second where the rule 2 is added* after the creation of the SAD entry
> >    >for the rule 1 (*: after in time, before in order).
> >   
> >    section 4.4.1 concludes with a brief section:
> >   
> >   Handling Changes to the SPD while the System is Running
> >   
> >   If a change is made to the SPD while the system is running, a check
> >   SHOULD be made of the effect of this change on extant SAs. An
> >   implementation MAY choose to check the impact of an SPD change on
> >   extant SAs and to provide a user/administrator with a mechanism for
> >   configuring what actions to take, e.g., delete an affected SA, allow
> >   an affected SA to continue unchanged, etc.
> >   
> >    i think this addressed your concern.
> >   
> >=> yes but this conflicts with the end of 4.4.2:
> >
> >    For each of the selectors defined in Section 4.4.1.1, the entry for

question about 2401bis tunnels and fragments

The following discusses some of the text regarding fragmentation and 
tunnel mode. I checked the archives, and although fragmentation issues 
have been discussed numerous times, I did not find that this particular 
issue had been covered. If it has, can someone please point me at the 
thread; if not, I'd like to raise it now (it's a minor editing issue, IMO).

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

Some of the descriptions on page 13/14 about the need for tunnel mode 
are indeed needs for tunnels (e.g., reassembly), but not necessarily 
need tunnel mode, e.g.:

 > Several concerns motivate the use of tunnel mode for an SA involving
 > a security gateway. For example, if there are multiple paths (e.g.,
 > via different security gateways) to the same destination behind a
 > security gateway, it is important that an IPsec packet be sent to the
 > security gateway with which the SA was negotiated.  Similarly, a
 > packet that might be fragmented en-route must have all the fragments
 > delivered to the same IPsec instance for reassembly prior to
 >
 >
 > Kent & Seo              [Page 14]
 > 
 > Internet Draft  Security Architecture for IP  September 2004
 >
 >
 > cryptographic processing. Also, when a fragment is processed by IPsec
 > and transmitted, then fragmented en-route, it is critical that there
 > be inner and outer headers to retain the fragmentation state data for
 > the pre- and post-IPsec packet formats. Hence there are several

Re:

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

Re: revised IPsec Architecture draft (2401bis)

Francis,
>
>    However, I do not see why you
>    feel that the 4.4.2 text conflicts with the text at the end of 4.4.1.
>
>=> a possible action of the end of 4.4.1 is to update the selectors of
>an affected SA, this is forbiden by the MUST of 4.4.2. IMHO the problem
>is in the wording, i.e., "contain" should be changed by "be filled by"
>or something else catching the idea the selectors are dynamic and
>*always* reflect the SPD as a cache does.

I see your point. The phrase "the SAD MUST contain the value or 
values  negotiated at the time the SA was created" is the sticking 
point. We will reword that to reflect the possibility that the SAD 
entry was updated as a result of an SPD change.

Steve