Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
RFC 5386

Note: This ballot was opened for revision 07 and is now closed.

(Jari Arkko) Yes

Comment (2008-01-23 for -)
No email
send info
> o  A new flag for SPD entries: 'BTNS_OK'.  

Somehow the start of this bullet item does not flow
naturally in the same way as the rest of the bullet list
does.

>       3   PUBLICKEY:any         ANY       by-IP
> 
> The last entry is the BTNS entry.

BTNS wildcard entry?

(Sam Hartman) (was Discuss, Yes) Yes

(Chris Newman) Yes

Comment (2008-01-20 for -)
No email
send info
I find this document short and clear, which is refreshing.  Furthermore,
I consider this an important first step to making IPsec actually useful
for application protocols (another necessary step would be to document
Posix-style APIs that a cross-platform application can use to query the
OS about 1. whether IPsec/BTNS is in use, 2. a description of any
security layer provided for application logging at a minimum,
3. channel bindings).

We need more protocols that consider the usability impact of zeroconf.

(Tim Polk) (was No Objection, No Record, Discuss) Yes

Comment (2008-01-23)
No email
send info
Section 2, the last sentence of the paragraph following the second list ("To preserve IPsec
access control semantics:") states "A single pass implemenattion that meets this requirement
is permitted."  This is a bit ambiguous, since a number of requirements were articulated
in the preceding text.  Perhaps "A single pass implementation with functionally equivalent
behavior is permitted." would be clearer.

The security considerations section should include a pointer to the problem and applicability
statement.

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Russ Housley) No Objection

Comment (2008-01-18 for -)
No email
send info
  This change was suggested in the Gen-ART Review by Vijay K. Gurbani:
  >
  > s/[RFC4301]'s concepts./concepts discussed in [RFC4301]./
  >
  > This seems like a good idea to me. Please make the change.
  
  Vijay also made a suggestion about Section 3.  He points out that the
  use of square brackets makes references to the hosts and security
  gateways seem like document references.  Another convention would be
  better.  Vijay suggests parenthesis or curly braces.  Either one is
  fine with me.

  Based on the SecDir Review by Scott Kelly, it seems like a good idea
  to add a reference to the BTNS problem statement document to the
  security considerations section of this document.  Please do so.

(Cullen Jennings) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

Comment (2008-01-24 for -)
No email
send info
Please expand MITM at first occurence.

(David Ward) No Objection

Magnus Westerlund No Objection