Re: draft-ietf-v6ops-cpe-simple-security-04 WGLC

[Brian E Carpenter <[e-mail]>]

IMHO this is an important document, and almost ready to be a BCP, but
a few points need attention:

It pains me to say it, but I think the following sentence in the
Overview section should simply be deleted:

  "It should be noted that NAT for IPv6 is both strictly forbidden by
   the standards documents and strongly deprecated by Internet
   operators."

There's no way this sentence won't be controversial at the IESG stage,
and any attempt to wordsmith it will be highly painful for all concerned.
Deleting it doesn't change the value or recommendations of the draft.

At the bottom of page 4:

  "As the latest revision of this document is being drafted,
   conventional stateful packet filters are activated as a side effect
   of outbound flow initiations from interior network nodes."

I can't parse this sentence. What does "are activated" mean? By who, in
which boxes? And does the first clause just mean "Today, " ?

"2.1.  Basic Sanitation

   In addition to the functions required of all Internet routers
   [RFC4294], residential gateways are expected to have basic stateless
   filters for prohibiting certains kinds of traffic with invalid
   headers, e.g. martian packets, spoofs, routing header type code zero,
   etc."

I think 'martian' needs a definition.

Also, should this section say something about ICMP in general?


In section 2.2:
  "To prevent Teredo from
   acquiring a utility that it was never meant to have on networks where
   both IPv4/NAT and native IPv6 services are available, gateways MUST
   impede Teredo tunnels by blocking clients from learning their mapped
   addresses and ports in the qualification procedure described in
   sections 5.2.1 and 5.2.2 of [RFC4380]."

Just to avoid silly misunderstandings, could we
s/gateways/gateways on such networks/ please?
Also, I don't think we can justify MUST; how about SHOULD?

Also, should this topic also cover 6to4? Hosts behind an IPv6 CPE
SHOULD NOT use host 6to4 based on RFC3068.

However, I have to wonder why this whole topic (Teredo+6to4) is
relevant to this document. Shouldn't it be in the CPE requirements
document instead?

  "R2: Packets bearing in their outer IPv6 headers multicast destination
   addresses of equal or narrower scope that the configured scope
   boundary level of the gateway MUST NOT be forwarded in any direction.
   The DEFAULT scope boundary level SHOULD be organization-local scope."

I can't find a definition of "organization-local scope" or even what
is meant by "configured scope boundary level". Probably the document needs
a short discussion of what it means by "scope".

  "R5: Packets MAY be discarded if the source and/or destination address
   in the outer IPv6 header is a unique local address.  By DEFAULT,
   gateways SHOULD NOT forward packets across unique local address scope
   boundaries."

I would insert a normative reference to RFC4193.

  "R28: If a gateway cannot determine whether the endpoints of a TCP
   connection are active, then it MAY abandon the state record if it has
   been idle for some time.  In such cases, the value of the
   "established connection idle-timeout" MUST NOT be less than two hours
   four minutes."

Two hours four minutes?

"3.3.2.  SCTP Filters"

Reading this section, I wondered whether there is anything to say
about SHIM6? A TCP session over SHIM6 could simply appear, with
no SYN/ACK, or disappear, as the shim switches addresses.

  "R31: Gateways MUST implement a protocol to permit applications to
   solicit inbound traffic without advance knowledge of the addresses of
   exterior nodes with which they expect to communicate.  This protocol
   MUST have a specification that meets the requirements of [RFC5378],
   [RFC3979], [RFC4748] and [RFC4879]."

It sounds good but it doesn't tell a CPE implementor what to code.
Also, is it really part of simple security?

I'm not sure that I have a constructive suggestion, but maybe the
hard requirement should be more firewallish: gateways must not
allow unsolicited inbound traffic by default? With the solicitation
mechanisms being out of scope for this document?

  "Much of the text describing the detailed requirements for TCP and UDP
   filtering is derived or transposed from [RFC5382] and [RFC4787], and
   some form of attribution here may therefore be appopriate."

I fear you will need to insert the pre-RFC5378 disclaimer.

  ** Obsolete normative reference: RFC 4748 (Obsoleted by RFC 5378)

  -- Obsolete informational reference (is this intentional?): RFC 3989
     (Obsoleted by RFC 5189)

   Brian