Subject: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences

From: Pekka Nikander <[email-masked]>
Date: Sun, 15 Jun 2003 11:20:19 +0300

Based on our experiences in the SEND WG, I would like
to offer the following comments to the IPSEC WG, regarding
to the AHbis draft.

 > 1.  Introduction
 >
 >  ....
 >
 >  host.  ESP may be used to provide the same anti-replay and similar
 >  integrity services, and it also provides a confidentiality
 >  (encryption) service.  The primary difference between the integrity
 >  provided by ESP and AH is the extent of the coverage. Specifically,
 >  ESP does not protect any IP header fields unless those fields are
 >  encapsulated by ESP (e.g., via use of tunnel mode). ...

Comments:

  - Even though the text above is true and correct, it may give a wrong
    impression.  The most important difference is packet size.  If ESP
    is used, it is necessary to copy all the important information from
    the fields that precede ESP into ESP (typically by employing
    tunneling), thereby making the packet larger.  Additionally, if the
    protocols protected by ESP rely on any fields that precede ESP, ESP
    processing should check that the fields within the ESP header and
    the fields outside of it are equal.  This is, by no means, trivial,
    since tunnel mode is not always a solution, depending on context.

    Hence, I would suggest adding the following piece of text:

    It should be noticed that some applications (such as IPv6
    Neighbor Discovery or Mobile IPv6) rely on the integrity of some
    of the fields in the IP header.  Furthermore, using tunnel mode
    may not be an option, since the very precense of a tunnel may
    open attacks.  Finally, the incresed packet size caused by
    tunneling may be unacceptable to some applications.

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

 > 3.2  Integrity Algorithms
 >
 >  The integrity algorithm employed for the ICV computation is specified
 >  by the SA.  For point-to-point communication, suitable integrity
 >  algorithms include keyed Message Authentication Codes (MACs) based on
 >  symmetric encryption algorithms (e.g., AES [AES] or on one-way hash
 >  functions (e.g., MD5, SHA-1, SHA-256, etc.).  For multicast
 >  communication, a variety of cryptographic strategies for providing
 >  integrity have been developed and research continues in this area.

Comment:

  - In the current SEND working group proposal, a public key algorithm
    is proposed to be used even for point-to-point communication.
    However, this probably does not warrant changing the text above.

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

 > 3.4.2  Security Association Lookup
 >
 >  ....
 >  document.)  The SAD entry for the SA also [...]
 >  indicates the key required to validate the ICV.

Comment

  - In the current SEND WG proposal, the SA does not indicate the key
    to be used.  Instead, the AH header itself contains the public
    key.  However, I don't know if the text above should be changed.

--Pekka Nikander
   SEND WG co-chair

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 16 Jun 2003 10:31:54 +0300

[Resending to the ipsec list, the original did not get through.]

Comments:

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

Comment:

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

Comment

--Pekka Nikander
   SEND WG co-chair

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 16 Jun 2003 10:47:56 +0300

One more comment to the AHbis WG LC:

AHbis currently states the following:

> 2.4  Security Parameters Index (SPI)
> 
> The SPI is an arbitrary 32-bit value that is used by a receiver to 
> identify the SA to which an incoming packet is bound. For a unicast 
> SA, the SPI can be used by itself to specify an SA, or it may be used
> in conjunction with the IPsec protocol type (in this case AH). 
> Since, for unicast SAs, the SPI value is generated by the receiver, 
> whether the value is sufficient to identify an SA by itself, or 
> whether it must be used in conjunction with the IPsec protocol value 
> is a local matter.  The SPI field is mandatory and this mechanism for
> mapping inbound traffic to unicast SAs described above MUST be 
> supported by all AH implementations.

However, in the SEND WG we are using AH with public key crypto,
with a fixed SPI.  There the key used depends on the sender of
the message, not the receiver.  Hence, for our purposes neither
the SPI alone nor SPI + protocol are enough.  We need also the ability
to select the SA based on SPI + source address, even for unicast.

> If an IPsec implementation supports multicast, then it MUST support 
> multicast SAs using the following algorithm for mapping inbound IPsec
> datagrams to SAs. ...  Each entry in the Security Association
> Database (SAD) [KA98a] must indicate whether the SA lookup makes use
> of the source and destination IP addresses, in addition to the SPI.
> ... (There is no current requirement to support SA mapping based on
> the source address but not the destination address, thus one of the
> possible four values is not meaningful.) ....

Since we are using PK crypto, we also need the possibility for
selecting the SA based solely on the source address.  In fact,
for our fixed SPI, the destination address does not have any role,
not even whether the destination address is unicast or multicast.

I don't know how to handle this so late in the process.  I would
like to see the text to be sufficiently revised to allow source
address based SA selection, so that we could use it directly in SEND.
However, I have no idea how the IPSEC WG would feel about that.

--Pekka Nikander
   SEND WG co-chair

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 15 Jun 2003 10:22:49 +0300

Barbara Fraser wrote:
> This is a working group last call for comments on the following drafts, 
> for progression to Proposed Standard:
> 
> ...
> draft-ietf-ipsec-rfc2402bis-03.txt

Enclosed a set of minor comments to the rfc2402bis draft.

I am reviewing the draft from the SEND WG point of view, and
these comments are ones that do involve any SEND specific issues.
However, even though these are really minor, they are not purely
editorial, and may have some WG interest.

I will shortly send another set of comments, more from the SEND WG
point of view.

--Pekka Nikander
   SEND WG co-chair

> 2.2  Payload Length
> 
>    This 8-bit field specifies the length of AH in 32-bit words (4-byte
>    units), minus "2".  (This means of expressing the length of AH was
>    selected to allow its use as an IPv6 extension header. Thus the
>    length computation is consistent with the algorithm described in RFC
>    1883.)  In the case of an integrity algorithm that yields a 96-bit
>    authentication value, plus the 3 32-bit word fixed portion, this
>    length field will be "4". See Section 2.6, "Integrity Check Value
>    (ICV)", for comments on padding of this field, and Section 3.3.3.2.1
>    "ICV Padding".

Comments: 

 - Shouldn't the reference to RFC1883 be replaced with a reference
   to RFC2460, or better, to [DH95]?

 - It is probably far too late to change this, but all the other 
   IPv6 extension headers define the length in 8-octet units, 
   not 4-byte units.  If possible, it *would* be desirable to 
   update this for IPv6.  However, I fully understand that such
   a change may not be possible at this late in standardization.
   (This comment may be ignored, as it most probably has been
    extensively discussed in the past by the WG.)

 - For IPv6, there should be a requirement that the length MUST
   be integral in 8-octet units, i.e., that the length must be
   evenly divisible by two.  The requirement for that does exist
   in 3.3.3.2.1, but it would be good to briefly repeat it here.

   Suggestion:  Insert the following text before "See Section 2.6"

     For IPv6, the total length of the header must be a multiple of
     8-octet units.  

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

> 2.3  Reserved
> 
>    This 16-bit field is reserved for future use.  It MUST be set to
>    "zero." (Note that the value is included in the ICV calculation, but
>    is otherwise ignored by the recipient.)

Comments:

 - Why is the value of the field defined as it is?  The more usual
   wording seems to be 'MUST be set to "zero" by the sender, and
   SHOULD be ignored by the recipient'.  The effect of the text above
   is the same, but someone may try to read it is the value must
   always be zero, and e.g. implement a firewall that drops packets
   where it is non-zero.

   Suggestion:  Replace with the following text.

     This 16-bit field is reserved for future use.  It MUST be set to
     "zero" by the sender, and it SHOULD be ignored by the recipient.
     (Note that the value is included in the ICV calculation, but is
     currently otherwise ignored by the recipient.)

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

> 3.3.3.1.2.1  Base Header Fields
> 
>    The IPv6 base header fields are classified as follows:
> 
>    Immutable
>              Version
>              Payload Length
>              Next Header (This should be the value for AH.)

Comments:

 - The note in the paranthesis is both unnecessary and misleading,
   as there may well be intevening extension headers.  

   Suggestion:  Remove the text in paranthesis.

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

>    [DH95]    Deering, S., and B. Hinden, "Internet Protocol version 6
>              (IPv6) Specification", RFC 1883, December 1995.

Comments:

 - Should this be replaced with a reference to RFC 2460?

   Suggestion: Replace with a reference to RFC2460.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 16 Jun 2003 10:31:13 +0300

[Resending to the list, the original did not get through.]

--Pekka Nikander
   SEND WG co-chair

Comments: 

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

Comments:

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

Comments:

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

Comments:

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jun 2003 13:59:00 -0400

At 10:47 AM +0300 6/16/03, Pekka Nikander wrote:
>>whether it must be used in conjunction with the IPsec protocol 
>>value is a local matter.  The SPI field is mandatory and this 
>>mechanism for

It sounds like SEND would like to use the AH format, but has a 
processing model that is not aligned with the way IPsec uses SAs in 
general.  We had extensive discussion in this WG about demuxing for 
inbound IPsec traffic after the MSEC folks expressed concern about 
the current process last fall. The demuxing spec has been very stable 
for several YEARS; we tweaked it very slightly for MSEC, after 
considerable debate and analysis, to accommodate SSM.  Your proposed 
change represents yet another bit of complexity for an IPsec 
implementation and I question whether the WG ought to agree to such a 
change at this late date.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Jun 2003 01:55:39 +0300

...
> change at this late date.

If I undestand correctly Pekka is asking that the document does not
say you MUST NOT allow source address based SA selection (I do not
thing it currently says so). I assume that if it does not say anything
that this is forbidden or even better says that implementation MAY
support SA selection based on the SPI and source address, he will be
happy.

Even if the document says "MAY" to this thing, it does not require
anybody to change anything nor does it make any implementations
non-conforming. We are simply allowing implementations to also have
this kind of features too.

I.e adding something like this to the text:

"The SPIs from the reserved range may used different demultiplexing
algorithms and use source and/or destination address and/or protocols
and/or some other information for the actual demultiplexing. A
document describing new reserved SPI number MUST also specify the
demultiplexing algorithm used for that specific SPI."
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jun 2003 22:12:53 -0400

>demultiplexing algorithm used for that specific SPI."

Tero,

The primary motivation in the IETF for developing standards is to 
promote interoperability. What you seem to suggest is a that we not 
preclude someone from saying that they comply with IPsec, even though 
they would be following a demuxing policy that is not used in any 
extant implementations and thus would not be interoperable with any 
of these implementations.  This does not promote interoperability; 
all it does is allow someone to claim conformance with a standard. 
That does not seem constructive and, as I noted, it only add to 
complexity.

Am I missing something in your suggestion?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jun 2003 23:05:11 -0400

>    tunneling may be unacceptable to some applications.

The extant text is correct. Until SEND has a comprehensive, coherent 
model for using AH that does not require changes to other parts of 
IPsec processing, I think it is appropriate to retain the current 
text.

No, it does not.

This is not consistent with the IPsec specs! Remember that a protocol 
such as AH is not just syntax; it also encompasses the rules for 
processing packets.  In IPsec, the SAD entry for an SA stores the 
keys that are employed to process packets. In turn, the SAD entry is 
located by using the SPI from an inbound packet (for unicast 
traffic). If SEND wants to use AH then you need to use the protocol 
(including the processing spec) as defined in IPsec, not just the 
syntax from 2402. Suggesting that we change AH to accommodate SEND's 
possible use of it, in a fashion not consistent with the current 
specs, is asking quite a lot.

Steve

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Jun 2003 01:00:23 -0400

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

I think that we are rushing the 2401bis/ESPbis/AHbis. I agree that there
are lots of nice things that people want out there (64-bit replay
counters, etc.), but I think that for AH in particular, we should
let SEND do its thing first.

I see no one waiting for AHbis to go forward.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Jun 2003 09:09:01 +0300

> >"The SPIs from the reserved range may used different demultiplexing
					 ^ => use
> >document describing new reserved SPI number MUST also specify the
					       ^ => must
...
> of these implementations.

I have little problems of parsing what you are saying above, but what
I said there does not affect interoperability at all, as it does not
change any current implemenation to conforming or non-conforming.

If the implementation wants to follow the AHbis then it must implement
the demux policy that is MUST in it. This text does not change that.
What that text says (or at least tries to say) is that there is future
work in progress that might use different demuliplexing policies IN
ADDITION to the current ones, and those future documents will define
them later.

What this means to implementator is that if he feels he might be
wanting to comply to those (future) documents later he might want to
write implementation so that new demultiplexing policies can also be
used.

The only MUST (or perhaps it should be "must") in my text was for the
future document writers, not to any implementator. For implementators
we just give hint that "yes, there is work going on, and you might
want to create your architecture so that it can handle those future
demultiplexing algorithms".

> This does not promote interoperability; 

It will be conforming to the AHbis if and only if it implements the
demultiplexing algorithms specified as MUST in the AHbis. This text
does not change it. It will be conforming to some other future
documents if it implements demultiplexing algorithms specified there.
This text will not change that either.

Only thing I was (trying) to say in the text was that "be prepared,
there is other demultiplexing algorithm(s) coming in the future
documents".

> That does not seem constructive and, as I noted, it only add to 

Adds complexity to where? I do not thing it changes anything in the
implementations unless you plan to implement those future documents,
and it will not change any bits in the wire, nor can you remove any of
the current demultiplexing algorithm currently mandated by AHbis. 

> Am I missing something in your suggestion?

I think so.

---

From: [email-masked]
Date: Wed, 18 Jun 2003 15:38:08 +0900

>So the real questions are:
>Is there any use for the AH as it is now specified?
>What are application(s) / protocol(s) which will use it?

	i believe there are real use of AH, we have been using AH to protect
	BGP sessions, and i'm about to write up a draft to use AH for protecting
	RIPng conversation among routers.

	even if there's very little use of AH in the community, major change
	to AH that SEND requires would require another IP protocol #, IMHO.

itojun

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Jun 2003 02:47:05 -0400

I agree strongly with Tero.

I said for years that AH would get used - but certainly not for VPNs. That
we didn't know where it would be important, that it would be.
SEND is a customer here.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 18 Jun 2003 09:28:25 +0300

> specs, is asking quite a lot.

The SEND is a user of the AH. Are there any other real users for the
AH? In earlier days there was people saying that we should remove the
whole AH as nobody uses. Now there seems to be SEND that is using it,
but they want to do something differently. Do we want to say to our
(only?) user that no we do not allow you to do anything differently?

Do we want them to create another protocol replacing their use of AH?
Another people who have been saying that they want to use AH is Mobile
IP people. What do they want? Is the current spec fine with them or do
the want similar processing than SEND?

Actually they quite often want to do demultiplexing based on the
fields inside the mobility or routing header not the outer IP address.
I.e they might need different demultiplexing algorithm too.

If we cannot answer to those questions I think we should drop the
current AH from the IPsec WG and say that SEND/Mobile IP etc can
specify it so that it will be suitable for them :-)

I do not want any generic text saying "someone might want to use it if
the phase of the moon is full and ..., and,... and ... export control
... and ... goverment ... and ...".

I do want current real word example (where the current AH as specified
in the current document) is actually used or is planned to be used. I
do NOT see any use for the AH on the VPNs or road warriors IPsec
clients. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 18 Jun 2003 10:34:31 +0300

Stephen Kent wrote:
>> selecting the SA based solely on the source address.  In fact, for
>> our fixed SPI, the destination address does not have any role, not
>> even whether the destination address is unicast or multicast.

> general.

Right now, yes indeed.  With the proposed change of moving the
public key to a separate extension header, thereby generating
a one-message "inline" KMP, not really, IMHO.

> We had extensive discussion in this WG about demuxing for inbound
> IPsec traffic after the MSEC folks expressed concern about the 
> current process last fall. The demuxing spec has been very stable for
> several YEARS; we tweaked it very slightly for MSEC, after
> considerable debate and analysis, to accommodate SSM.

I sort of followed that discussion, but not very closely.  I can't
claim that I would remember all the details.

> Your proposed change represents yet another bit of complexity for an
> IPsec implementation and I question whether the WG ought to agree to
> such a change at this late date.

I am sorry of the late date.  My only excuse is that SEND has
only recently progressed to a level where we are able to
comment AHbis.

Returning to the real question, I actually claim that the
proposed change would simplify a typical implementation.
According to the current spec, you may have to handle unicast
and multicast addresses differently, and you have to implement
the restriction that the "use source address, don't use
destination address" is forbidden.

Remember, IPv6 ND requires multicast, and hence a conforming
implementation MUST implement the multicast demultiplexing
algorithm anyway.

One way of implementing the current specification is to
implement the two nominal bits into the SAD database, and
all the code required to check the source address, the
destionation address, both, or neither.  After that, one
would *add* the code to forbid the bit pattern indicating
that only the source address check sould be made.

 From an implementation point of view, these restrictions
are additional complexity, and removing them would reduce
complexity.  But maybe you had some other type of complexity
in mind?

Actually, the minimum change to AHbis would be to remove
the paranthesized sentence "(There is no current requirement
to support SA mapping based on the source address but not the
destination address, thus one of the possible four values is
not meaningful.)"  Adding some clarifying text, indicating
that if only the source address is used for demultiplexing,
then whether the destination address is multicast or unicast
does not matter, would be helpful, too.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 18 Jun 2003 10:14:45 +0300

Steve and Tero,

[Taking my SEND WG chair hat firmly *off*, i.e., speaking for
  myself only.]

Stephen Kent wrote:
> Until SEND has a comprehensive, coherent model for using AH that does
> not require changes to other parts of IPsec processing, ...

With all respect, I sincerely believe that SEND will never come up
with "a comprehensive, coherent model for using AH that does
not require changes to other parts of IPsec processing".  More on that
below.  If you disagree, please try to come up with a scheme where
you use AH when you

  - don't have any IP addresses (i.e. during IPv6 DAD)

  - do not know in which network you are (public access)

  - do not trust most nodes in the network (public access)
    - and are still trying to figure out what node(s) to trust,
      how much, and in which respects

  - do not know which of the potentially many trust roots you
    should use to establish trust with the possibly existing
    trusted nodes in the otherwise untrusted network

  - want to operate, at a lower level of security, when you
    are unable to establish pre-configured trust with anyone

  - want to make this all *effectively*, without using zillions
    of messges, since you potentially have to do this each time
    you roam to a different IP network

I still claim that there are situations where the integrity and
data origin authentication of the IP header is important.
Hence, I firmly believe that the text concerning the relationship
between AH and ESP is misleading at best and perhaps even outright
wrong.  Using tunnel mode is not an answer, at least sometimes.

>>   key.  ....
> This is not consistent with the IPsec specs!

Actually I more or less agree with you, Steve!  Indeed, that is
one of the reasons why I am proposing changes to the current AH
usage in SEND, basically moving the public key from the AH header
to a separate extension header, to be placed before the AH header.
(See the separate discussion at the SEND WG ML.)

> In IPsec, the SAD entry for an SA stores the keys that are employed
> to process packets. In turn, the SAD entry is located by using the
> SPI from an inbound packet (for unicast traffic).

I am very very well aware of that.  I quite well remember what
I learned while I implemented one of the early BITS IPsec stacks
as a part of my PhD work back in 1994-1995.

However, sometimes the SPI alone is not very useful, and sometimes
using the destination address as a selector is not the right choice.
(More on this on the separate thread.)

> If SEND wants to use AH then you need to use the protocol (including
> the processing spec) as defined in IPsec, not just the syntax from
> 2402. Suggesting that we change AH to accommodate SEND's possible use
> of it, in a fashion not consistent with the current specs, is asking
> quite a lot.

I agree.  Actually, using the revised suggestion of moving the
public key from the AH header to a separate extension header,
thereby creating an "implicit" or "inline" one message KMP,
seems to simplify issue.  However, even in that case it
would really make sense to perform SA selection based on the
source address.  However, I defer that discussion to the other
thread.

Tero Kivinen wrote:
> The SEND is a user of the AH. ... Do we want to say to our

As Itojun pointed out (and Steve well knows), SEND is indeed not
the only user of AH.  Anyway, thanks for your supporting words.

We should also remember that RFC2461/2462 explicitly states that
AH is the method to be used for protecting IPv6 ND.  That is, in fact,
quite doable if you have a static environment with pre-configured
security associations, PK based or symmetric.  However, once you
want to use AH in the public access environment, things get harder.
See the outline above.

> Do we want them to create another protocol replacing their use of AH?

This is the very question.  There are lots of folks at the
SEND WG who believe so.  That is, they believe that AH should
not be used for securing IPv6 ND, and a separate protocol should
be developed instead.

> Another people who have been saying that they want to use AH is 
> Mobile IP people. What do they want? Is the current spec fine with 
> them or do the want similar processing than SEND?

Having been there too (though recently not very actively), I strongly
suspect that some of the MIPv6 requirements will be fairly similar
to those of SEND.  Both deal with IP address mappings, MIP with
IP -> IP mappings and ND with IP -> lladdr mappings.

> What are application(s) / protocol(s) which will use it?

I think Itojun answered to these.

> specify it so that it will be suitable for them :-)

Thanks.  See the other thread at saag.

> I do NOT see any use for the AH on the VPNs or road
> warriors IPsec clients.

Here I tend to agree with you, Tero, but that is really beside
the point of this discussion, IMHO.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 18 Jun 2003 10:51:42 +0300

Steve and Tero,

>> support SA selection based on the SPI and source address, he will be

I would be quite happy if the AHbis allowed source address
based selectors even implicitly.  Right now it has the paranthesized
sentense saying that the particular nominal bit pattern is not
meaningful, thereby implicitly forbidding selecting SA using
only the source address.

>> demultiplexing algorithm used for that specific SPI."

I don't even need this much to be said.  Just removing the
paranthesized sentence would be mostly enough.

Let me reiterate here why source address based selection would
be useful.  Right now SEND carries a public signature key and
other parameters in the AH header, and uses only one AH SA
which extracts the key from the header, checks the validity of
the key either with CGA or against certificates, and verifies
the signature.  I tend to agree with Steve that this is not
really consistent with the IPsec model.

Hence, what I have proposed is to move the key and associated
data from the AH header to a separate extension header that
would precede the AH header in processing order.  In this scheme,
the extension header creates an AH SA on the fly.  (Didn't
SKIP do something like this?)  If CGA is used, the AH SA is
only valid for processing this single packet; if certificates
is used, the lifetime of the SA depends on what the certs and
what the local policy state.

When the AH header is handled, the SA is already there, and
AH just does the "usual thing", in this case checks the
signature.

The problem is really how to find the right SA.  Destination
address is not the answer, since the scheme must work both
with multicast and with unicast.  With multicast only you
perhaps could use a combination of destination and source
addresses, but not with unicast.  In many cases you
don't have any state associated with the destination node,
you are just replying to a multicast message.

You can't really allocate a new SPI in the inline KMP,
since you have only one message, and the destination
selects the SPI values to be used.

Consequently, the only reasonable field to use for selecting
the right SA would be the source address.  Furthermore, that
would be the logical choice, since the public key is directly
related to the source address anyway.

I hope this makes this all clearer.

--Pekka Nikander

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 Jun 2003 07:52:48 -0700

Steve,

> Am I missing something in your suggestion?

I read Tero's suggested text as only applying to a new SPI in the
reserved region. It would therefore promote interoperability for that
SPI, but should not impact any other. Perhaps the text needs to be
strengthened to make this clearer?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 18 Jun 2003 08:29:11 -0700

Just to clarify a bit to what Pekka has said (and with my SEND WG
chair hat on).

Mobile IP faced some similar issues to what SEND is currently facing
in the area of securing binding updates to correspondent nodes, which
caused them to abandon AH and develop a new protocol.

In SEND, we have a reasonably complete design using AH based on a
reserved SPI that would work with RSA, but it does require an
implementation for the SA that behaves somewhat differently from the
two standard cases of a manual SA or an SA established with IKE. Pekka
has suggested some baseline changes in the design that would reduce
the IPsec implementation work, so most of these differences are due to
the fact the public key is being used, some are due to other factors
around the particular application. Depending on what you believe the
reserved SPI were for, this could be viewed either as an unnecessary
complexity or an extension.

That said, there is strong feeling from some security-knowledgable
SEND WG members and a major vendor that reviewed the initial design
that too many changes would be required in IPsec, and that SEND should
also develop a new protocol. We'll be discussing a proposal from Jari
Arkko on the list and at the meeting to use ND options rather than AH,
despite the fact the AH was specified in RFC 2461/2462. This is
something we've been very strongly trying to avoid, since the intent
of SEND was to be very conservative. There is no concensus in the WG
at the moment about which way to go, since we've just begun the
discussion.

Now removing my WG chair hat and more or less quietly and
inobtrusively slipping on my IAB hat (but not, of course, in any way
speaking for the IAB), these two cases where AH has been tried to
secure IP signaling traffic and found significant difficulties suggest
that there might be a more fundamental problem involving securing IP
signaling that might benefit from some additional attention. From
Ito-jun's email, it sounds like he has examples of cases where AH out
of the box works with securing BGP updates, so the perhaps there is a
class of IP signaling security problems that can be solved by AH.
Knowing the boundaries of that class might be helpful.

            jak

----- Original Message -----
From: "Pekka Nikander" <[email-masked]>
To: "Tero Kivinen" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>; <[email-masked]>; "SEND
WG" <[email-masked]>
Sent: Wednesday, June 18, 2003 12:14 AM
Subject: SEND vs. IPsec AH (was Re: Comments on
draft-ietf-ipsec-rfc2402bis-03.txt...)

> --------------------------------------------------------------------
> To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
> body to <[email-masked]>.
> Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
> --------------------------------------------------------------------
>

---

From: [email-masked]
Date: Thu, 19 Jun 2003 11:32:57 +0900

>I'm not sure how significant the changes are, e.g. much of it can be seen
>as the properties of a new algorithm.

	draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol
	proposal (not a new algorithm) to me.  AH needs to fall into what is
	defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond
	what defined in RFC2402.

itojun

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jun 2003 22:42:20 -0400

>(only?) user that no we do not allow you to do anything differently?

The way you seem to want to use AH is so different from normal IPsec 
processing as to warrant having a different protocol, in my view. You 
can't just appropriate the name of the protocol and its syntax, but 
change the processing model.

>the want similar processing than SEND?

Good question.

>I.e they might need different demultiplexing algorithm too.

Then we have a BIG problem. So far I have not seen a mature proposal 
from mobile IP that requires what you suggest.

>Is there any use for the AH as it is now specified?

Very little. But, that does not mean that one can redefine it and 
still have it be part of IPsec.

>What are application(s) / protocol(s) which will use it?

This is not the right question. The question is whether AH does what 
you want for SEND. if not, and if the changes are significant, then 
create a different protocol.

>specify it so that it will be suitable for them :-)

The SEND WG can create its own protocol, but there is no technical 
rationale for reusing the AH name. Reuse would only cause confusion.

>do NOT see any use for the AH on the VPNs or road warriors IPsec

We appear to disagree on the ground rules. You seem to be suggesting 
that AH is like an abandoned ship, and whoever gets to it first can 
claim the name and redefine it :-) If IPsec has no continuing use for 
AH, then maybe we can retire the protocol number after a few years, 
but we seem to have some folks who suggest otherwise. I think the 
best course is to define a protocol that does what SEND needs and not 
try to twist AH into that protocol.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jun 2003 23:32:04 -0400

>strengthened to make this clearer?

reserved SPIs are a holdover from the early days of IPsec and are 
generally not used. But, the change in processing that has been 
proposed is simply not consistent with the overall IPsec processing 
model and saying that it applies to only this one SPI does not make 
life better. I'm afraid that this is just a bad fit.

Steve

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 19 Jun 2003 07:54:58 +0300

Itojun,

> 	defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond

I more or less agree with you.  In fact, I have proposed moving
the keying material into a separate header, as I have explained
in length in other messages.  If such a change is made, the role
of AH would be within the purpose of RFC2402, IMHO.

This issue will be discussed in Vienna; we've reserved time
for it at the SEND WG meeting.  See the proposed WG agenda
at the SEND ML.

Now, independent on that, the newest version of the said draft
is draft-ietf-send-ipsec-01.txt

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 19 Jun 2003 11:05:37 +0300

Steve,

Tero Kivinen wrote:
>> The SEND is a user of the AH. ...

A major reason why why SEND currently uses AH is that Bellovin
suggested that at the Yokohama BoF.  James and I, as WC chairs,
felt that we should at least *attempt* the way suggested by an AD.
However, as it should be clear from this on-going discussion, it
is far from clear if that is the right way.  Personally, I believe
that it indeed is, but others clearly disagree.

> change the processing model.

I have already addressed this in a separate message.  As a summary
of that: if we are speaking about the current WG proposal, I tend to
agree with you , but I also think that the issues can be solved fairly
easily, with just a minor technical change to AHbis.

>> Do we want them to create another protocol replacing their use of AH?

Indeed.

> Very little. But, that does not mean that one can redefine it and still 
> have it be part of IPsec.

Just out of curiosity: How do you define IPsec?  RFC2401?

> rationale for reusing the AH name. Reuse would only cause confusion.

In my (in this case very) humble opinion, I think that the question
of reusing the AH name depends on the intent of the protocol, not
only on its syntax.  If the goal is the same, to provide integrity
and data origin authentication for the whole IP packet, including the
immutable or predictable header fields, then I think that the protocol
could and should be called AH.  If it uses public key crypto, and
thereby creates (conceptual) Security Associations that are associated
with the source of the packet rather than the destination, even for
unicast, that does not change the intent.

OTOH, I do agree that embedding KMP functionality into the AH header
does not sound that good an idea.  However, it did not appear to me how
to separate the KMP functionality before I started to implement the
current SEND proposal.

AH has a long history.  I think it would be better to return to the
some early goals of AH rather than to deprecate it and start anew.

--Pekka Nikander

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Jun 2003 23:26:39 +0300

Nevertheless, I'm personally in favor of a SEND approach which
uses ND options. More details at
http://www.piuha.net/~jarkko/publications/send/dafts/draft-send-ndopt.txt

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Jun 2003 23:57:47 +0300

>> the want similar processing than SEND?

Mobile IPv6 does not employ AH. Most of the security solution
in MIPv6 is in the "application" layer. It does use ESP
for one thing, namely the protection of signaling between
the mobile node and its home agent where traditional
security associations can be assumed to exist. It does
place some requirements on IPsec, but the requirements
for SEND are tougher.

I still think current SEND approach is within the bounds
of the IPsec architecture. And I think it would be a good
idea for the IETF to think where it will apply AH, and
what its future role is. However, I suspect an ND layer
solution would be a surer bet, mainly because in SEND
it would have access to all information, such as some
of the addresses that don't appear in the IP header.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 19 Jun 2003 08:02:14 -0700

Itojun,

> defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond

Could you clarify? What specifically leads you to conclude that SEND should
be a new algorithm? I'm particularly interested in understanding what your
feelings are about what should and should not be legitimately included under
one of the reserved SPI before a protocol should be separated.

            jak

---

From: [email-masked]
Date: Fri, 20 Jun 2003 11:12:38 +0900

>one of the reserved SPI before a protocol should be separated.

	none of existing algorithm for AH defines structure within AH
	authentication data.  therefore i assume AH algorithm to be some
	crypto-checksum algorithm, not a new protocol definition.

	for instance, if you write a program to support the draft, SEND use
	of AH would require certain amount of new code for parsing SEND
	authentication data packet format, not just a set of calls to crypto-
	checksum algorithm.  AH packet processing should not be that different
	depending on SPI value.

itojun

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Jun 2003 12:52:52 -0400

>    you roam to a different IP network

I don't disagree that SEND has a number of security constraints with 
which it must deal. However, AH was not designed to address this set 
of constraints and thus trying to twist AH to meet the needs of SEND 
is inappropriate.

>wrong.  Using tunnel mode is not an answer, at least sometimes.

The IPsec WG does not seem to share this view, based on previous, 
extensive discussions. We rarely have circumstances where AH makes 
more sense than ESP in either tunnel or transport mode. And, there is 
a strong desire in the WG to simplify the IPsec specs, which runs 
counter to your suggestion.

>(See the separate discussion at the SEND WG ML.)

There is NO public key in the AH header. There is a place for an ICV.

>(More on this on the separate thread.)

I don't think this WG  has identified a set of contexts in which the 
current SA selection mechanisms are not sufficient.  We made some 
changes to accommodate MSEc requirements, but it's very late in the 
process to assert that there needs to be fundamental changes to this 
mechanism.

>source address.  However, I defer that discussion to the other

As noted above, there was NEVER a provision to carry ANY key in the 
AH header, so this whole thread seem rather odd to me.

>want to use AH in the public access environment, things get harder.

The RFC numbers cited above obviously refer to specs issued after the 
IPsec specs were published.  I don't think the IPsec WG can be 
responsible for what other WGs may choose to say about how to use the 
protocols developed here, but I think it fair to say that maybe 
someone made an assertion without thinking it through.

>not be used for securing IPv6 ND, and a separate protocol should

I'm all in favor of that, if the alternative is to make the sort of 
changes you suggest to AH, to accommodate SEND requirements.

>IP -> IP mappings and ND with IP -> lladdr mappings.

We have had interactions with folks about mobile IPv6 and its uses of 
IPsec. A previous version of the ID was held up in the IESG because 
it seemed to suggest changes to IPsec that had not been agreed to by 
this WG.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2003 18:07:58 -0400

At 11:05 AM +0300 6/19/03, Pekka Nikander wrote:

	<SNIP>

>Just out of curiosity: How do you define IPsec?  RFC2401?

RFC 2401 defines IPsec processing and semantics. ESP and AH are the 
two subscriber traffic protocols whose syntax is separately defined. 
We put the common processing and context discussion in 2401, to avoid 
repetition. I do not view AH and ESP as protocols that should be 
viewed outside of the context of 2401.

>to separate the KMP functionality before I started to implement the

Embedding key management data in the transit traffic headers is what 
SKIP proposed a long time ago. The IPsec WG spent over 2 years 
arguing about this before we adopted IKE.

>some early goals of AH rather than to deprecate it and start anew.

Some of the early goals are no longer relevant, e.g., because of the 
advent of integrity-only ESP.

Steve

---

From: Francis Dupont <[email-masked]>
Date: Mon, 30 Jun 2003 14:06:26 +0200

In your previous mail you wrote:

   Comments: 

=> thsi was proposed (by me) and refused at the previous AH revision
some years ago. So IMHO it is far too late.

Regards

[email-masked]

---

From: "Theodore Ts'o" <[email-masked]>
Date: Mon, 30 Jun 2003 13:03:23 -0400

Steve,

Part of the problem here is that we are trying to put AH and ESP to
bed before we take up the RFC 2401 revisions.  The SEND working group,
on the suggestion of Steve Bellovin, has essentially proposed a new
key management scheme, uses an IP extension header to "establish"
keying material which can then be used by the AH and ESP.  

I agree that it hasn't been fully specified in sufficient detail yet,
but the basic premise does seem sound.  To the extent that much of the
processing rules are in 2401, as you have pointed out, does it make
sense to perhaps delete the few sentences that outright prohibit what
the SEND working group is trying to do, and defer that discussion for
2401-bis discussion, just so we can send the AH and ESP documents to
the IESG and get them off our hands?  I agree that a protocol is not
just syntax, but semantics too.  However, much of the semantics is
alreayd in architecture document, and we do have precedent for
attempting to allow AH and ESP to be used by mutliple keying
mechanisms beyond just IKE.  (i.e., SKIP, Multicast Keying, etc.)

						- Ted

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2003 13:21:07 -0400

>mechanisms beyond just IKE.  (i.e., SKIP, Multicast Keying, etc.)

Ted,

We killed SKIP a long time ago, and I think that was the right 
decision :-) The reserved SPI feature was a holdover from that time, 
and maybe it too should go, to avoid giving folks the wrong 
impression.

I am not yet comfortable with making these changes to accommodate 
SEND, given the current status of the IPsec documents, the maturity 
of the SEND work, etc.  I suggest you ask Russ for his direction 
before we proceed.

Steve