headers
Karen Seo | 1 Mar 2004 19:27
Picon

Re: IPsec -- new versions of AH and ESP

Folks,

I've re-submitted these 2 drafts to the IETF secretariat.  Note: 
Given the ongoing IETF, they may not get posted right away.

Karen
Permalink | Reply | 2 comments |
headers
Michael Richardson | 1 Mar 2004 23:51
Picon

Announce: FreeS/WAN Project Ending


From http://www.freeswan.org/ending_letter.html

-----BEGIN PGP SIGNED MESSAGE-----

Dear FreeS/WAN community,

After more than five years of active development, the FreeS/WAN project will be 
coming to an end.

The initial goal of the project was ambitious -- to secure the Internet
using opportunisitically negotiated encryption, invisible and convenient 
to the user. (for more, see http://www.freeswan.org/history.html).
A secondary goal was to challenge then-current US export regulations, 
which prohibited the export of strong cryptography (such as triple DES 
encryption) of US origin or authorship. 

Since the project's inception, there has been limited success on the 
political front. After the watershed Bernstein case (see
http://www.eff.org/Privacy/Crypto_export/Bernstein_case/ )
US export regulations were relaxed. Since then, many US companies have exported 
strong cryptography, without seeming restriction other than having to notify 
the Bureau of Export Administration for tracking purposes.

This comfortable situation has perhaps created a false sense of security.
The catch? Export regulations are not laws. The US government still 
reserves the right to change its export regulations on short notice, and 
there is no facility to challenge them directly in a court of law. This leaves 
the US crypto community and US Linux distributions in a position which seems 
safe, but is not legally protected -- where the US government might at any time
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Kent | 2 Mar 2004 09:13
Picon

Re: ICMP messages and per-port selectors

At 10:07 +0100 2/26/04, Jean-Jacques Puig wrote:

	<SNIP>
>
>  > We're not guaranteed
>>  that the 64-bytes we get with an IPv4 ICMP message will have porty
>>  fields, for example, so it is not always as easy as reversing the
>>  addresses and ports to match against an extant SA.
>
>Can you give an example of these 64 BITS not carrying the adequate
>information for upper layer selectors check ? Note that non-initial
>fragments are not allowed in ICMP errors, and that the original data
>should be *at least* 64 bits (as for rfc1122).

I was thinking about the added IPsec header, and ICMP messages 
returned via an intermediate gateway (not over an SA). in those cases 
we will not have access to the protocol or the port fields.  but for 
an ICMP arriving via an SA, we should get the necessary info.

the issue here is one of relative performance impacts for ICMP 
traffic sent or received via an SA. if we don't have a separate SA 
for such traffic, then I'm not sure we need to add selectors for ICMP 
type/code values, but we do find ourselves having to afford special 
treatment for ICMP traffic both on transmission and reception, if we 
don't segregate this traffic.

we have to look at tghe ICMP payload, retrieve addresses and ports 
and flip them, and use these values plus the protocol to locate the 
right SA for outbound traffic. if we have an ICMP SA, then we don't 
have to do that work. we have to do the same sort of work if one of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Roe | 2 Mar 2004 19:56
Picon
Favicon

draft-ietf-rfc2401bis-01: editorial nits


(1) On page 14: "There are two nominal databases in this model ..." 
                "A third database, the Peer Authorization Database ..."

     Wouldn't it be better to say that there are THREE nominal databases in the model?
     (Unless you think that the PAD is somehow not part of the model).

(2) On page 33: "Note: The source address that appears in the encapsulating
    tunnel header MUST be the one that was negotiated during the SA establishment
    process."

    Should this be the destination address, not the source address? (Dst addr + SPI
    will uniquely identify the SA unless it's multicast)

Cheers!
Mike
Permalink | Reply | 3 comments |
headers
Michael Roe | 2 Mar 2004 19:40
Picon
Favicon

Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01

Karen, Steve,

In draft-ietf-rfc2401bis-01, the description of the processing
model is very confusing. The problem is that is keeps switching
between two different representations of the SPD:

 (a) An ordered SPD, which may contain overlapping entries
 (b) An unordered SPD, which must not contain overlapping entries

So we have:

[page 16] "The SPD is an ordered database,..."  - ordered SPD

[page 17] "An SPD is logically divided into three pieces, all of
which should be decorrelated ..."  - unordered SPD

[page 17] "The management interface for the SPD ... MUST support
(total) ordering of these entries, as seen via this interface." 
 - ordered SPD

It seems as though the description of packet processing is based on an
UNordered SPD; implementors may at their discretion implement it either
as an ordered or an unordered datastructure; and as a conformance
requirement, the management user interface MUST present the user with
the appearance of an ordered SPD, using the Annex B algorithm to translate
if necessary.

I appreciate that technical changes are unwelcome at this point, but I thought
I ought to try and explain why the current text is confusing.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Kent | 2 Mar 2004 22:24
Picon

Re: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01

Mike,

Thanks for the feedback.  We will go back and try to clarify the 
description in the places you noted.  We may need to refer to the SPD 
and the decorrelated SPD, with the former as the default unless 
otherwise qualified, to avoid this confusion.

Steve
Permalink | Reply | 2 comments |
headers
Mark Duffy | 3 Mar 2004 01:13

comments on 2401bis-01 - Transport mode by SGs

I just finished reading through draft-ietf-ipsec-rfc2401bis-01.txt and I 
found it much clearer than 2401.  A big thank you to the authors and other 
contributors!

I have a few questions on the content which I will spread over several 
messages.

Regarding use of transport mode by security gateways in sect. 4.1 it states:

    A transport mode SA is a security association typically employed
    between a pair of hosts to provide end-to-end security services. When
    link (vs. end-to-end) security is desired between two intermediate
    systems along a path, ...

It seems a bit of a misnomer to refer to this as "link security" since it 
may in fact span multiple links.  I propose referring to this instead as 
"intermediate system to intermediate system security."

                      ... transport mode MAY be used between security
    gateways or between a security gateway and a host.  In the latter
    case, transport mode may be used to support IP-in-IP [Per96] or GRE
    tunneling [FaLiHaMeTr00] over transport mode SAs.

Even in the former case (SG to SG) shouldn't the use of transport mode be 
limited to cases where some in-IP tunnelling mechanism is used?  But, it 
might not be IP-and-IP or GRE; it could be L2TP, MPLS-in-IP, etc.  So I 
suggest rewording this passage as follows:

    A transport mode SA is a security association typically employed
    between a pair of hosts to provide end-to-end security services. When
(Continue reading)

Permalink | Reply | 3 comments |
headers
Greg Troxel | 3 Mar 2004 01:34
Picon

Re: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01

  From: "Michael Roe" <mroe <at> microsoft.com>

  In draft-ietf-rfc2401bis-01, the description of the processing
  model is very confusing. The problem is that is keeps switching
  between two different representations of the SPD:

   (a) An ordered SPD, which may contain overlapping entries
   (b) An unordered SPD, which must not contain overlapping entries

I had a similar reaction on reading the draft, but was lame about
commenting.

Since decorrelation is "just" an optimization, my (unconsidered)
preference is to have all the descriptions be in terms of the ordered
SPD, perhaps with 'the packet is looked up in the SPD' explained once,
and then that definition simply used.  The decorrelation presentation
could then be descriptive, with the authoritative rules for lookup be
in terms of the ordered SPD.

There is another, more subtle issue, which is that any time the SPD is
changed any data structures derived from the SPD should be updated.
While this typically course includes computing a new decorrelated SPD
to enable fast lookups, it may also be necessary to revisit extant SAs
in implementations that omit SPD lookups when a packet matches an SA,
since an SA match may no longer indicate reliably that the packet is
allowed by the SPD.  Decorrlating the SPD doesn't _cause_ this issue,
but I believe it makes it harder to see.

--

-- 
        Greg Troxel <gdt <at> ir.bbn.com>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephen Kent | 3 Mar 2004 02:28
Picon

Re: Ordered and unordered SPD in draft-ietf-ipsec-rfc2401bis-01

At 19:34 -0500 3/2/04, Greg Troxel wrote:
>   From: "Michael Roe" <mroe <at> microsoft.com>
>
>   In draft-ietf-rfc2401bis-01, the description of the processing
>   model is very confusing. The problem is that is keeps switching
>   between two different representations of the SPD:
>
>    (a) An ordered SPD, which may contain overlapping entries
>    (b) An unordered SPD, which must not contain overlapping entries
>
>I had a similar reaction on reading the draft, but was lame about
>commenting.
>
>Since decorrelation is "just" an optimization, my (unconsidered)
>preference is to have all the descriptions be in terms of the ordered
>SPD, perhaps with 'the packet is looked up in the SPD' explained once,
>and then that definition simply used.  The decorrelation presentation
>could then be descriptive, with the authoritative rules for lookup be
>in terms of the ordered SPD.

the problem is that our new model for processing flow uses caches, 
which require a decorrelated SPD.

Steve
Permalink | Reply | 0 comments |
headers
Paul Hoffman / VPNC | 3 Mar 2004 03:13

Re: IPsec -- new versions of AH and ESP

At 1:27 PM -0500 3/1/04, Karen Seo wrote:
>I've re-submitted these 2 drafts to the IETF secretariat.  Note: 
>Given the ongoing IETF, they may not get posted right away.

As usual, temporary versions of these documents are available at:

<http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-esp-v3-08.txt>
<http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-rfc2402bis-07.txt>

These files will disappear when the real copies appear in the 
Internet Drafts directory.

--Paul Hoffman, Director
--VPN Consortium
Permalink | Reply | 1 comment |

Gmane