Skip to main content

Last Call Review of draft-ietf-savi-threat-scope-
review-ietf-savi-threat-scope-secdir-lc-roca-2011-05-31-00

Request Review of draft-ietf-savi-threat-scope
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-05-24
Requested 2011-05-07
Authors Danny R. McPherson , Fred Baker , Joel M. Halpern
I-D last updated 2011-05-31
Completed reviews Genart Telechat review of -07 by David L. Black (diff)
Secdir Last Call review of -?? by Vincent Roca
Assignment Reviewer Vincent Roca
State Completed
Request Last Call review on draft-ietf-savi-threat-scope by Security Area Directorate Assigned
Completed 2011-05-31
review-ietf-savi-threat-scope-secdir-lc-roca-2011-05-31-00
Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The security section, though small, provides a good discussion of what
can or cannot be expected from the SAVI approach. I appreciate this
effort. 

A few comments:

** The second paragraph explains that identifying the host that
originated a packet is not the same as identifying the end user.
I agree. It seems to me that the goal of the third paragraph is to
further elaborate on the idea that identifying the end user is complex
(and sometimes meaningless). However this is not clearly stated. 


** It is said (last paragraph):
"...source addresses must not be used as an authentication mechanism."
I suggest using an uppercase "MUST NOT".


** It is said (last sentence):
  "The only technique to unquestionably verify source addresses of a
   received datagram are cryptographic authentication mechanisms such as
   IPsec."
Well, IPsec per se does not check the source address of a packet but
provides an authentication service of the remote IPsec entity (e.g. the
other IPsec tunnel endpoint). The packet integrity guarranty provided is
only limited to the path secured by IPsec and this path may not encompass
the effective packet sender.

Regards,

   Vincent