Subject: 2401bis-00 submitted to IETF

From: Karen Seo <[email-masked]>
Date: Sat, 18 Oct 2003 03:44:21 -0400

Folks,

I just submitted 2401bis-00 to the IETF publications folks.  This draft:
	a. incorporates changes for all the issues that seem
	   reasonably settled.
	b. indicates the sections that may change based on unresolved
	   issues (below).

The issues that are not included are:
	40,44,45	new processing model
	46		nested/bundled SAs
	49		red sided fragmentation (haven't heard back from
			Mark Duffy re: suggestion about OPAQUE ports)
	50/85		I put in a version of your text but this
			issue is clearly still on the list from a MAY
			vs MUST point of view and because they've issued
			a new proposed paragraph (issue 87)
	67		IPsec management traffic destined locally
	75		TOS (now DSCP/ECN) copying in tunnel mode
	82		clarification re: creation of SAs
	85 		dropped inbound packet -- does not match SA

Please note that Steve provided numerous inputs but in an attempt to 
maintain plausible deniability, he spent 2 weeks in Europe, was back 
for 3 days and then flew away to Washington for meetings on Thursday 
and Friday.  So he did not get to review this draft.

Thank you,
Karen

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 21 Oct 2003 10:39:29 -0700

Since it might take a while for the draft to get posted in the 
official IETF repository, there is a temporary copy of the draft 
available at 
<http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-rfc2401bis-00.txt>. 
This temporary copy will disappear when the official copy hits the 
official repository.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Mike Taylor" <[email-masked]>
Date: Tue, 21 Oct 2003 17:46:42 -0700

I'm just getting to the point in my IPSec development where I need
to start dealing with whatever issues arise related to ICMP error
message processing, as discussed in

	Section 6. ICMP Processing Relevant to IPSec

of 2401.

I was just pondering the following language again in of 2401 when I received
the
email the draft:

   "An ICMP error message protected by AH or ESP and generated by a
   router SHOULD be processed and forwarded in a tunnel mode SA.  Local
   policy determines whether or not it is subjected to source address
   checks by the router at the destination end of the tunnel."

I see that it has not been reworded in the draft.  I suppose the meaning
should be
obvious to me, but being somewhat dense it isn't.

What does the above mean?  It can't really refer to the case, as a literal
interpretation might suggest, that we have received an ICMP error message
that has already had ESP or AH applied.  Obviously in that case we should
do the same thing with it as we would any other IP datagram we receive
where the proto is AH or ESP - look it up in the SADB based on the SPI,
protocol,
and destination, and go from there.

So initially I thought it was referring to the same type of issue as with
PMTU, i.e.,
where we receive an ICMP error message from a router that contains an IP
datagram
with proto AH or ESP that appears to have been sent by the SG (i.e., sent on
one
of its tunnels).  Is that the intent?  For example, suppose that the router
is
reporting that the SG at the other end of the tunnel is unreachable.  Then
we would
have to synthesize a DUR to send back to hosts on the trusted network
similarly
to how the handling of PMTU is described in Appendix B, except perhaps that
local
configuration could prevent us from doing this.

So I'm concerned that I'm missing something important.  Another reason I
find it confusing
is that a few paragraphs later we have

   "An ICMP message not protected by AH or ESP is unauthenticated and its
   processing and/or forwarding may result in denial of service.  This
   suggests that, in general, it would be desirable to ignore such
   messages."

Now is it the intent of this paragraph that we would be desirable not to
forward ICMP error messages from one end of a VPN to the other?  In other
words,
that we shouldn't take red ICMP error messages coming in from one end of the
VPN,
apply IPSec, and send them in the tunnel ultimately to the red network at
the
other end of the VPN?  That can't be.  Surely we want to do that.  We have
to
be able to trust ICMP error messages we receive from within the trusted
network.
Wouldn't make for much of a VPN if we couldn't.

So I'm afraid I'm missing something fundamental here.  Whether I am, or am
not
missing something, either way it seems to me that much of the text
in Section 6 of the new draft ought to be reworded to clarify the meaning.

Thanks,

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Paul Hoffman / VPNC
> Sent: Tuesday, October 21, 2003 10:39 AM
> To: [email-masked]
> Subject: Re: 2401bis-00 submitted to IETF
>
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Oct 2003 08:57:45 -0400

Mike,

We're still working on a major new section on ICMP processing that 
replaces the old 2401 text.  It should be out relatively soon, as a 
new issue, though it is not in the draft that was just released. 
Let's see how your questions are addressed by the new text.

Steve

P.S.  Again, note the correct spelling is "IPsec", not "IPSec." 
2401bis will make an explicit point of this, as per the WG chairs' 
request.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 22 Oct 2003 09:37:48 -0400

>and destination, and go from there.

It's not that easy. If we apply the SA selectors to the ICMP message, 
there is still the concern that the content of the message could be 
hostile, e.g., it might be a destination unreachable message for a 
host or net that is not consistent with the SA via which it was 
received. in our new text we explain why it is necessary to send this 
sort of traffic off for additional examination.

>Wouldn't make for much of a VPN if we couldn't.

no, this text refers to black ICMP messages.

>in Section 6 of the new draft ought to be reworded to clarify the meaning.

yes, the text is being revised significantly to be more comprehensive 
and clearer.

Steve