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

From: Yaron Sheffer <[email-masked]>
Date: Thu, 17 Sep 2009 23:28:12 +0300

This is to begin a 2 week working group last call for draft-ietf-ipsecme-esp-null-heuristics-01. The target status for this document is Informational.

Please send your comments to the ipsec list by Oct. 1, 2009, as follow-ups to this message.

Note that this document has had very little review until now. We will only progress it as a WG document if we have at least 3 non-editor, non-WG chair reviewers who have read it and approve of it. And yes, this means the pseudocode, too. There has been strong support of ESP-null detection, so this document is likely to be widely implemented. Your review will mean a lot to the technical quality of this document.

Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also indicate the nature or severity of the error or correction, e.g. major technical, minor technical, nit, so that we can quickly judge the extent of problems with the document.

The document can be accessed here:
http://tools.ietf.org/html/draft-ietf-ipsecme-esp-null-heuristics-01

Thanks,
            Yaron

Email secured by Check Point

Email secured by Check Point

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 21 Sep 2009 16:01:18 -0400

Here are my comments:

- Is Section 1.2 necessary?  None of these terms are used in this fashion 
in this document.
- page 8, "sees an new" => "sees a new"
- page 8, "in the Section 8" => "in Section 8"
- page 12, excessive space in "i.e.  UDP encapsulated"; perhaps replace 
with comma.
- page 16, "with a new SA which needs heuristics" => "produces a new SA 
which needs heuristics and will benefit from the existing flows".
- page 21, "things what needs" => "things that need"
- page 21, suggest "optimize things" => "optimize steps", just to reduce 
repetition
- page 21, "For example implementation" => "For example, implementations"
- page 25, I believe that DES-MAC has a 64-bit ICV (FIPS 113) and KPDK has 
a 128-bit ICV (RFC 1828).
- page 30, for tunnel mode checks it might be worth just mentioning that 
tunnel mode is inferred by protocol 4 for IPv4 and protocol 41 for IPv6.

At a high level the pseudocode seems ok to me, although there is a lot of 
mutual interaction between these functions due to the global state, so it 
can certainly benefit from as much scrutiny as possible.

Overall I approve of this document.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Yaron Sheffer <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Date:
09/17/2009 04:28 PM
Subject:
[IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01

This is to begin a 2 week working group last call for 
draft-ietf-ipsecme-esp-null-heuristics-01. The target status for this 
document is Informational.

Please send your comments to the ipsec list by Oct. 1, 2009, as follow-ups 
to this message.

Note that this document has had very little review until now. We will only 
progress it as a WG document if we have at least 3 non-editor, non-WG 
chair reviewers who have read it and approve of it. And yes, this means 
the pseudocode, too. There has been strong support of ESP-null detection, 
so this document is likely to be widely implemented. Your review will mean 
a lot to the technical quality of this document.

Please clearly indicate the position of any issue in the Internet Draft, 
and if possible provide alternative text. Please also indicate the nature 
or severity of the error or correction, e.g. major technical, minor 
technical, nit, so that we can quickly judge the extent of problems with 
the document.

Thanks,
            Yaron

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Sep 2009 13:47:03 +0300

> - Is Section 1.2 necessary?  None of these terms are used in this fashion 

True. Removed. 

> - page 8, "in the Section 8" => "in Section 8"

Fixed.

> - page 12, excessive space in "i.e.  UDP encapsulated"; perhaps replace 

xml2rfc seems to want to put it there, but that is something that can
be fixed in the final RFC editing phase.

> which needs heuristics and will benefit from the existing flows".

Fixed.

> - page 21, "For example implementation" => "For example, implementations"

Fixed.

> a 128-bit ICV (RFC 1828).

RFC4306 does not give reference to AUTH_DES_MAC, and the AUTH_KPDK_MD5
reference is to RFC1826 whic does not define it. I do not want to put
those there as both of them are actually quite unsecure and should not
be used anyways.

Changed to:

     // AUTH_DES_MAC and AUTH_KPDK_MD5 are left out from
     // this document.

> tunnel mode is inferred by protocol 4 for IPv4 and protocol 41 for IPv6.

Changed it to be:

     // Tunnel mode checks (protocol 4 for IPv4 and protocol 41 for
     // IPv6) is also left out from here to make the document shorter.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Sep 2009 15:20:14 +0300

I support advancing this document, and I think the explanations and  
pseudo code are good.

I do, however, question the value of it in real life.

Security policies or the deep inspection kind usually are something  
like:
  - allow HTTP and HTTPS, and verify headers
  - allow ICMP and DNS
  - maybe some more allowed protocols
  - drop everything else

I'm sure anything enforcing a policy like this will anyway drop ESP- 
non-null, because it doesn't look like one of those allowed protocols.  
However, YMMV so I support publishing this draft.

On Sep 17, 2009, at 11:28 PM, Yaron Sheffer wrote:

> This is to begin a 2 week working group last call for draft-ietf- 
> ipsecme-esp-null-heuristics-01. The target status for this document  
> is Informational.
>
> Note that this document has had very little review until now. We  
> will only progress it as a WG document if we have at least 3 non- 
> editor, non-WG chair reviewers who have read it and approve of it.  
> And yes, this means the pseudocode, too. There has been strong  
> support of ESP-null detection, so this document is likely to be  
> widely implemented. Your review will mean a lot to the technical  
> quality of this document.
>
> Please clearly indicate the position of any issue in the Internet  
> Draft, and if possible provide alternative text. Please also  
> indicate the nature or severity of the error or correction, e.g.  
> major technical, minor technical, nit, so that we can quickly judge  
> the extent of problems with the document.
>