[IPsec] Closing #22 (was: RE: Closing #25)

[Yaron Sheffer]

And this is exactly the table that I claim needs to remain in the spec. A list 
of errors - even if partial! - is essential to understanding a protocol.

Thanks,
Yaron

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Paul Hoffman
> Sent: Tuesday, November 24, 2009 4:38
> To: Keith Welter
> Cc: ipsec@ietf.org
> Subject: [IPsec] Closing #25
> 
> At 11:42 AM -0800 11/11/09, Keith Welter wrote:
> >A design team was convened including Dan McDonald, Tero Kivinen, Raj
> Singh, David Wierbowski and Keith Welter to resolve Issue #22.  The design
> team reached agreement on the following general approach as well as
> specific proposed text: . . .
> 
> Many, many thanks for all this work. I have now input all the text (with
> some wordsmithing and rearranging) in -06. However, I have changed one
> part:
> 
> At 11:42 AM -0800 11/11/09, Keith Welter wrote:
> >3.10.1. Notify Message Types (Updates)
> >...
> >NOTIFY messages: error types Value
> >---
> >...
> >TEMPORARY_FAILURE 40
> >See section 2.25.
> >
> >CHILD_SA_NOT_FOUND 41
> >See section 2.25.
> >
> >RESERVED TO IANA 42-8191
> >...
> 
> The values 40 and 41 *are already taken* in the IANA registry. I have
> substituted {TBA1} and {TBA2} for them in -06. (This reaffirms my desire
> to implement issue #123 and rip out the old tables.)
> 
> --Paul Hoffman, Director
> --VPN Consortium
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Yaron Sheffer]

Hi Paul,

Please add to Issue #123 a list of the affected tables. For example, I wouldn't 
imagine the list of notification types moving away, even though it's already 
been extended by IANA. Similarly for the stuff in Sec. 3.6, which is strongly 
related to descriptive text.

Thanks,
Yaron

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Steven Bellovin
> Sent: Tuesday, November 24, 2009 5:20
> To: Paul Hoffman
> Cc: ipsec@ietf.org; Dan McDonald
> Subject: Re: [IPsec] #123: Proposal to remove the IANA tables from
> IKEv2bis
> 
> 
> On Nov 23, 2009, at 8:46 PM, Paul Hoffman wrote:
> > I *really* don't think it is that hard for a developer to resolve a URL
> and read the tables there.
> 
> 
> Leave out the table; give the URL and mention 4306.  If you have two more-
> or-less authoritative sources for the same information, some folks will
> use one and some the other.  Point to the URL as *the* source, and say
> that it subsumes all values given in 4306.
> 
>   --Steve Bellovin, http://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Steven Bellovin]

On Nov 23, 2009, at 8:46 PM, Paul Hoffman wrote:
> I *really* don't think it is that hard for a developer to resolve a URL and 
> read the tables there.


Leave out the table; give the URL and mention 4306.  If you have two 
more-or-less authoritative sources for the same information, some folks will 
use one and some the other.  Point to the URL as *the* source, and say that it 
subsumes all values given in 4306.

--Steve Bellovin, http://www.cs.columbia.edu/~smb





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Closing #25

[Paul Hoffman]

At 11:42 AM -0800 11/11/09, Keith Welter wrote:
>A design team was convened including Dan McDonald, Tero Kivinen, Raj Singh, 
>David Wierbowski and Keith Welter to resolve Issue #22.  The design team 
>reached agreement on the following general approach as well as specific 
>proposed text: . . .

Many, many thanks for all this work. I have now input all the text (with some 
wordsmithing and rearranging) in -06. However, I have changed one part:

At 11:42 AM -0800 11/11/09, Keith Welter wrote:
>3.10.1. Notify Message Types (Updates)
>...
>NOTIFY messages: error types Value
>---
>...
>TEMPORARY_FAILURE 40
>See section 2.25.
>
>CHILD_SA_NOT_FOUND 41
>See section 2.25.
>
>RESERVED TO IANA 42-8191
>...

The values 40 and 41 *are already taken* in the IANA registry. I have 
substituted {TBA1} and {TBA2} for them in -06. (This reaffirms my desire to 
implement issue #123 and rip out the old tables.)

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Paul Hoffman]

At 8:37 PM -0500 11/23/09, Dan McDonald wrote:
>On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote:
>> >Can you move 'em to an appendix, with a permanent URL reference to the IANA
>> >up-to-date versions?
>>
>> As long as you mean "an appendix that clearly says 'these were in RFC 4306
>> but are now out-of-date but are here just for reference and you want to
>> look at '", I'm OK with that as well.
>
>I'd actually go one better -- snapshot what's on IANA today (or the day
>before RFC-editor pulls the switch) with the warning you quote ('... just
>for reference and you want to look at ').  The warning and URL is the
>critical part.

Oh, yuck. No. I could see doing this to keep the "bis" nature of the document 
intact by providing the old tables, but not creating a clone of the IANA 
registry. I *really* don't think it is that hard for a developer to resolve a 
URL and read the tables there.

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Dan McDonald]

On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote:


> The warning and URL is the critical part.

"are the critical part," - uggh, mustn't press Send so quickly.

Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Dan McDonald]

On Mon, Nov 23, 2009 at 05:27:36PM -0800, Paul Hoffman wrote:
> >Can you move 'em to an appendix, with a permanent URL reference to the IANA
> >up-to-date versions?
> 
> As long as you mean "an appendix that clearly says 'these were in RFC 4306
> but are now out-of-date but are here just for reference and you want to
> look at '", I'm OK with that as well.

I'd actually go one better -- snapshot what's on IANA today (or the day
before RFC-editor pulls the switch) with the warning you quote ('... just
for reference and you want to look at ').  The warning and URL is the
critical part.

Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Paul Hoffman]

At 8:12 PM -0500 11/23/09, Dan McDonald wrote:
>On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote:
>
>> This has flummoxed a few reviewers. Tables such as those in section 3.3.2
>> are already out of date because things have been added since RFC 4306. I
>> propose that we remove all these tables from IKEv2bis, and add notes
>> pointing to the current IANA registries. I cannot see how doing this lookup
>> will hurt developers: in fact, it forces them to actually look at the
>> up-to-date tables. I can see how we might want to leave the tables in, but
>> it really is confusing.
>
>Can you move 'em to an appendix, with a permanent URL reference to the IANA
>up-to-date versions?

As long as you mean "an appendix that clearly says 'these were in RFC 4306 but 
are now out-of-date but are here just for reference and you want to look at 
'", I'm OK with that as well.

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Closing #25

[Paul Hoffman]

At 9:46 AM +0200 10/21/09, Yoav Nir wrote:
>A few lines above this section it already says "If the responder's policy 
>allows it to accept the first selector of TSi and TSr, then the responder MUST 
>narrow the traffic selectors to a subset that includes the initiator's first 
>choices."
>
>So there is a MUST requirement to select the initiator's first choice (if 
>possible), so I don't think the SHOULD and MAY are appropriate here. The way I 
>read this section, it only clarifies what to do if the initiator traffic 
>selector (first or not) is too broad. In that case, we shouldn't mention the 
>initiator's choices.
>
>On Oct 20, 2009, at 6:19 PM, Paul Hoffman wrote:
>
>>Issue #25, Choice of the right TS when narrowing
>
>>Proposed change:
>>  When narrowing is done, there may be several subsets that are
>>  acceptable but their union is not.  In this case, the responder
>>  SHOULD select the initiator's first choice (to be interoperable
>>  with RFC 4306), but MAY arbitrarily select any of them,
>>  and MAY include an
>>  ADDITIONAL_TS_POSSIBLE notification in the response.

God call. I have closed #25 without making any change.

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Dan McDonald]

On Mon, Nov 23, 2009 at 04:37:22PM -0800, Paul Hoffman wrote:

> This has flummoxed a few reviewers. Tables such as those in section 3.3.2
> are already out of date because things have been added since RFC 4306. I
> propose that we remove all these tables from IKEv2bis, and add notes
> pointing to the current IANA registries. I cannot see how doing this lookup
> will hurt developers: in fact, it forces them to actually look at the
> up-to-date tables. I can see how we might want to leave the tables in, but
> it really is confusing.

Can you move 'em to an appendix, with a permanent URL reference to the IANA
up-to-date versions?

Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Paul Hoffman]

This has flummoxed a few reviewers. Tables such as those in section 3.3.2 are 
already out of date because things have been added since RFC 4306. I propose 
that we remove all these tables from IKEv2bis, and add notes pointing to the 
current IANA registries. I cannot see how doing this lookup will hurt 
developers: in fact, it forces them to actually look at the up-to-date tables. 
I can see how we might want to leave the tables in, but it really is confusing.

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] #122: Integrity proposals with combined algorithms

[Dan McDonald]

On Mon, Nov 23, 2009 at 04:32:43PM -0800, Paul Hoffman wrote:
> The second sentence seems wrong. Proposed rewording:
>   For example,
>   [AEAD] specifies additional formats based on authenticated
>   encryption, in which the integrity algorithm is an inherent
>   part of the combined algorithm; in this case, the
>   integrity algorithm is specified as "none".

Yes, this is much clearer, given we have a well-defined "none" value for
integrity.

Dan
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] #122: Integrity proposals with combined algorithms

[Paul Hoffman]

The 4th paragraph of section 3.3 says "If an algorithm that combines encryption 
and integrity protection is proposed, it MUST be proposed as an encryption 
algorithm and an integrity protection algorithm MUST NOT be proposed." This 
means that an integrity protection algorithm can only be proposed with a 
Transform ID equal to NONE, given that a few paragraphs above, it says: 
"Combined-mode ciphers include both integrity and encryption in a single 
encryption algorithm, and are not allowed to be offered with a separate 
integrity algorithm other than "none"." We should thus make this clear in the 
4th paragraph.

HOWEVER, in section 3.3.2, in the table for transform types, it says:
   Integrity Algorithm (INTEG) 3   IKE*, AH, optional in ESP
  (*) Negotiating an integrity algorithm is mandatory for the
  Encrypted payload format specified in this document. For example,
  [AEAD] specifies additional formats based on authenticated
  encryption, in which a separate integrity algorithm is not
  negotiated.
The second sentence seems wrong. Proposed rewording:
  For example,
  [AEAD] specifies additional formats based on authenticated
  encryption, in which the integrity algorithm is an inherent
  part of the combined algorithm; in this case, the
  integrity algorithm is specified as "none".

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] #121: Rekeying IKE SAs: KEr errors and PRF question

[Paul Hoffman]

We earlier agreed in issue #50 to make the KEr in Section 1.3.2 (Rekeying IKE 
SAs with the CREATE_CHILD_SA Exchange) mandatory:
 <--  HDR, SK {SA, Nr, KEr}
Note that this is not in the current draft, but will be in the next one.

So, what happens if the responder does not include a KEr, following the syntax 
in RFC 4306?  Does the process revert back to using only the SK_d and the new 
nonces, or does the responder reject the request and indicate its preferred DH 
group in the INVALID_KE_PAYLOAD notification payload (section 1.3)? The latter 
seems much more likely, given the text in 2.18. If so, we should say so 
explicitly.

Section 2.18 also states that in the case of the old and new IKE SA selecting 
different PRFs, that the rekeying exchange (for SKEYSEED) is done using the 
*old* IKE SA's PRF.  What happens after that?  The end of section 2.18 says 
that SK_d, etc are computed from SKEYSEED as specified in section 2.14.  If the 
PRF changed, which PRF is used for the prf+ calculations, the old PRF or the 
new PRF?

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Hiroshima meeting minutes posted

[Paul Hoffman]

They are at ; please 
let Yaron or I know if you find any errors. 

FWIW, Gabriel got them to us almost immediately after the meeting, so the 
lateness is the fault of your WG chairs, not of the minutes-taker.

--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-02.txt

[Internet-Drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working 
Group of the IETF.


Title   : Heuristics for Detecting ESP-NULL packets
Author(s)   : T. Kivinen, D. McDonald
Filename: draft-ietf-ipsecme-esp-null-heuristics-02.txt
Pages   : 35
Date: 2009-11-23

This document describes an algorithm for distinguishing IPsec ESP-
NULL (Encapsulating Security Payload without encryption) packets from
encrypted ESP packets.  The algorithm can be used on intermediate
devices, like traffic analyzers, and deep inspection engines, to
quickly decide whether given packet flow is interesting or not.  Use
of this algorithm does not require any changes made on existing
RFC4303 compliant IPsec hosts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] draft-ietf-ipsecme-esp-null-heuristics-02.txt

[Tero Kivinen]

Submitted now a new version of the heuristics draft, which includes
changes from Williams, Mononen, Richardson, Graveman and Moononen.
This should now include all changes that were requested, if I missed
some, send me a note.

Draft can already be found from the ietf repository

http://www.ietf.org/id/draft-ietf-ipsecme-esp-null-heuristics-02.txt

but it takes some time before it appears to the tools site (i.e. if
you want to get diffs etc):

http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] comments on esp-null-heuristics-01

[Tero Kivinen]

Michael Richardson writes:
> >As end nodes might be able to
> >   bypass those checks by using encrypted ESP instead of ESP-NULL, these
> >   kinds of scenarios also require very specific policies to forbid such
> >   circumvention.
> 
> The question is, are these end-nodes malicious, or are they just
> ignorant?

Good question, and I do not have good answer to that, as I do not
think we have clear threat model for WESP / heuristics. 

> >   Because the traffic inspected is usually host to host traffic inside
> >   one organization, that usually means transport mode IPsec is used.
> 
> It is?  I'll bet 95% of actual transport mode IPsec has an L2TP layer inside.

Inside one enterprise? I do not think so. I guess most of the IPsec
traffic is VPN style tunnel mode, but as that is going over untrusted
networks (there is word private there :) they are encrypted, thus
outside the scope of this draft.

Same goes with the L2TP transport mode cases.

I added a note there saying:

  Note, that most of the current uses of the IPsec are not host to
  host traffic inside one organization, but for the intended use cases
  for the heuristics this will most likely be the case. Also tunnel
  mode case is much easier to solve than transport mode as it is much
  easier to detect the IP header inside the ESP-NULL packet.

> I agree with the analysis of section 3, in particular the explanation of
> how hardware can be programmed to statefully match the ESP-NULL flows.
> It might be worth noting that NAT-T ESP-NULL flows *ALREADY* have a
> 5-tuple (likely unique) marker, and that if the inspector is also a NA(P)T,
> that it already is keeping the right state.

Do you have any exact wordings where to add what. 

> section 4.
> 
> It might be worth having a reference for "flow cache". I think that
> there is a document on Cisco Netflow, and I also think that FORCES has
> something that relates to the Linux "flow" things.  I think it might
> also be worth staying that this is really a "microflow" cache.

I added new terms to terminology section saying:

   Flow

  TCP/UDP or IPsec flow is a stream of packets part of the same TCP/
  UDP or IPsec stream, i.e.  TCP flow is a stream of packets having
  same 5 tuple (source and destination ip and port, and TCP
  protocol).

   Flow Cache

  Deep inspection engines and similar use cache of flows going
  through the device, and that cache keeps state of all flows going
  through the device.

   IPsec Flow

  IPsec flow stream of packets having same source IP, destination
  IP, protocol (ESP/AH) and SPI.  Strictly speaking source IP does
  not need to be as part of the flow identification, but as it can
  be there depending on the receiving implementation it is safer to
  assume it is always part of the flow identification.

> Include a forward reference to section 7, so the reader knows UDP will
> be dealt with.  In particular, in the text relating to NAT-T
> encapsulated IKE packets.   If they are not allowed through (queue until
> sure, or drop option), then the SA might not get setup ever..

Hmm... I think it should be enough to cover UDP encapsulation in the
section 7, do you really think we need forward reference from here? If
so, can you give me some exact text?

> section 8.2
> 
> I'd rather see the math/calculations in a display... that would
> eliminate the difficulty in reading when things are wrapped.

Done. 

> page 16:
> 
>those cases the packet must be marked "unsure".
> 
> s/must/MUST/ ???

I do not use RFC2119 words in the document as this is not really
protocol description. Changed the text to: In those cases the packets
are marked as "unsure".

> In conclusion: while I think the whole inspection notion is ridiculous,
>and likely is going to get in the way of deployment of
>new protocols, and may well help the "throttlers"
>(cf. Mark Handley's Net Neutrality presentation at
>IETF75), I find that if the inspection people follow the
>very sage advice of Kivinen and McDonald, that the least
>amount of harm possible will be done.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-01

[Tero Kivinen]

Tero Mononen writes:
> Overall comments:
> 
>   The draft contains quite a lot of background information (what you are
>   trying to achieve on technical point of view, what were the
>   alternative solutions considered). Part of this background is also
>   available on WESP draft.
> 
>   Making this draft an information disclosure on "algorithm to
>   determine if IPsec ESP packet stream has been encrypted or not",
>   without too much explanation or hand waving would increase its
>   usability. The background could be find by-reference on the WESP
>   RFC.

I think having background information in this document also makes this
document easier to understand. WESP document actually has quite a
little of the background information.

>   Please consider adding definitions/glossary entries for the
>   following concepts: flow, flow-cache. I know they are relevant on
>   certain implementations, but not necessarily well defined on that
>   sense, or at least introducing these terms properly before using
>   them.

I added terminology section and added those terms there.

> About the abstract:
> 
>   Consider changing abstract in a way that really points out the
>   good on this approach. Something like:
> 
> -8<---
> 
>   This document describes an algorithm for distinguishing IPSEC
>   ESP- NULL packets from encrypted ESP packets.  The algorithm can
>   be used on intermediate devices, like traffic analyzers, and deep
>   inspection engines, to quickly decide whether given packet flow is
>   interesting or not. Use of this algorithm does not require any
>   changes made on existing RFC4303 compliant IPSEC hosts.
> 
> -8<---

Changed.
-- 
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01

[Tero Kivinen]

Nicolas Williams writes:
> On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
> > Yes. That was what I tried to say. Do you think my already changed
> > sentence is ok, or do we need to explain it more.
> 
> Well, the heuristics will benefit from the information cached for the
> TCP/UDP flow over the previous SA.  "...benefit from the existing flows"
> doesn't quite get that point across (though it's the only realistic
> meaning).

Changed the text still more:

Generic protocol checking is much easier with pre-existing state.
For example, when many TCP / UDP flows are established over one
IPsec SA, a rekey produces a new SA which needs heuristics to
detect its parameters, and those heuristics benefit from the
existing TCP / UDP flows which were present in the previous IPsec
SA. In that case it is just enough to check that if a new IPsec SA
has packets belonging to the flows of some other IPsec SA
(previous IPsec SA before rekey), and if those flows are already
known by the deep inspection engine, it will give a strong leaning
that the new SA is really ESP-NULL.

> But surely actively trying to elicit retransmissions could be used
> as a way to get enough information to classify a flow...  The
> retransmissions should have different MACs, thus retransmissions
> help resolve ambiguities, even if the policy isn't to drop packets that
> cannot be inspected.

I would be quite hesitant to add text which actively tries to elicit
more retransmissions. If packets are dropped because of policy reasons
and that triggers retransmissions which helps heuristics, then that is
good. If packets are passed through then we can most likely use
heuristics over multiple packets to gain same information. 

> > If the policy is so that packets are passed, even when we cannot yet
> > inspect them, then the next packet still might be to the same flow.
> 
> I see.  Having a policy that says "drop packets that can't be inspected"
> actually helps resolve ambiguities if the end nodes retransmit.

Yes, but it also helps to resolve ambiguities, if we see multiple
packets to the same flow, i.e. get 3 TCP packets having same source
and destionation IP and ports, and first having SYN bit, next reply
having SYN/ACK and next one having ACK (with all of them with expected
sequence numbers etc).

> > enforcement and protection of the end node. One way to enforce
> > deep inspection for all traffic, is to forbid encrypted ESP
> > completely, in which case ESP-NULL detection is easier, as all
> > packets must be ESP-NULL based on the policy, and further
> > restriction can eliminate ambiguities in ICV and IV sizes.
>  ^
>s
> 
> Great!

Fixed. 

> A few more comments:
> 
>  - Should there be an explicit threat model in the document?

I am not sure if it belongs to this document, or to the WESP or as
separate document. I agree that having explicit threat model could
probably help understanding the problem, but I am not sure I am
correct person to write such.

> I think
>the threat model is this:
> 
> - End nodes trying to access inappropriate data, end nodes trying
>   sneak confidential data out, but without collusion with other end
>   nodes outside the network.
> 
> - Malware (since deep inspection could find malware and terminate
>   flows before malware downloads complete).
> 
>The first one shows how simple it is to defeat deep packet
>inspection: just find a peer to collude with.

There is also some cases where this can be used even when there is no
real threat, i.e. statics, and log gathering etc.

>  - A security considerations note about the security impact of forcing
>the use of ESP-NULL (and/or WESP) would be nice.  Specifically a note
>about the increased risk of sending confidential information where
>eavesdroppers can see it.

Added note:

Using ESP-NULL or especially forcing using of it everywhere
inside the enterprice can have increased risk of sending
confidential information where eavesdroppers can see it.

> The thought occurred that the pseudo-code could be expressed as a BSD
> Packet Filter program.  From what I can tell BPF does not have
> instructions by which one can implement state caching, but you could
> still implement, and _test_, large parts of the code in the appendix as
> BPF programs.  I wouldn't demand that -- it's a lot of work for a
> feature that we all seem to agree is not exactly hot (and it might mean
> doing implementation work for some vendors for free).

I do not expect the pseudo-code to include all required operations,
and I do not think it would be good idea to put executable code in the
RFC. It is meant to be as example pseudo-code, not final
implementation.

I think it might be better if someone could take that pseudo-code, and
implement as much as possible of it as BSD packet filter or some other
filtering language and put that out as open-so