Last Call Review of draft-ietf-softwire-gateway-init-ds-lite-

Request Review of draft-ietf-softwire-gateway-init-ds-lite
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-01-03
Requested 2011-12-21
Other Reviews Genart Last Call review of - by Vijay Gurbani (diff)
Review State Completed
Reviewer Tobias Gondrom
Review review-ietf-softwire-gateway-init-ds-lite-secdir-lc-gondrom-2012-01-05
Posted at
Draft last updated 2012-01-05
Review completed: 2012-01-05


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 Considerations of this document refer to four other
      documents. Unfortunately it does not state whether any new
      security issues are introduced by GI-DS-lite (or claims that no
      additional security issues are introduced by this spec).

      A few security questions come to mind reading the spec: 

      - is there an implication that it is allowed to establish the
      softwire between Gateway and AFTR at any point in time (not just

      - does the required uniqueness of combination of CID and SWID
      result in any attack vectors? 

      (btw. in section 3 do you mean "The combination of CID and SWID
      must be unique between gateway and AFTR" or "The combination of
      CID and SWID MUST be unique between gateway and AFTR"

      - to define that the translation scheme configuration will be done
      either manually or out-of-band seems to solve some security
      worries, however, does this imply these MUST be done manually or
      out-of-band (e.g. for security purposes)? 


      I am concerned about the weak or possibly not proper use of
      RFC2119 wording i

n wide parts of the

. In several cases I would expect
      RFC-2119 language instead of the currently used can/may/must (e.g.
      take a read of section 4 and 5).


      Section 1:

      s/GRE based encapsulation mechanisms is chosen/a GRE based
      encapsulation mechanism 

is chosen

      Best regards, Tobias