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

[james woodyatt <[e-mail]>]

On Apr 16, 2009, at 16:27, Brian E Carpenter wrote:
>
> 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.

My next revision deletes the entire paragraph containing this sentence.

> 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, " ?

It's a tough sentence to make work.  The idea I'm trying to describe  
here is the conventional method of creating state at the time of  
forwarding the initial packet for a new outbound flow to permit  
reverse path traffic to flow inbound.  I've got a candidate phrase in  
the next revision.

> "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.

Hmmm.  That could be an interesting tangent.  I thought I mostly  
covered the bases of what constitutes the martian addresses in IPv6 in  
section 3.1, but I suppose I could have added an explicit prohibition  
of packets with V4MAPPED addresses.  I didn't think that was  
necessary, and the design team didn't consider it, but I wouldn't  
object to adding it if there were calls for it here.

> 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?

No problem.

> Also, I don't think we can justify MUST; how about SHOULD?

I have no objection.

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

My assumption was that residential IPv6 CPE would normally prevent  
this by using RFC 1918 addressing behind their IPv4 NAT.  An explicit  
deprecation would only seem necessary in the case of IPv4/NAT gateways  
that translate between global addresses across the realm boundary.  I  
don't think those are very common, are they?

> 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.

Good idea.

>  "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?

The same reasoning as in RFC 5382, hence the informative reference.   
I'll insert an explicit reference into the recommendation paragraph.

>
> "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]."

I think I should relax both these MUST instances to SHOULD instances  
here.  The second sentence should probably have an 'if implemented'  
conditional phrase after the subject.

> It sounds good but it doesn't tell a CPE implementor what to code.

We can't very well tell them to code UPnP IGD for IPv6 until the UPnP  
Forum publishes a specification that meets our requirements.  We can't  
tell them to code ALD, because it's just a draft, and an expired one  
at that.  We might try to tell them to code MIDCOM, but I say good  
luck with that.

This recommendation is basically a stand-in for a more concrete  
recommendation once some kind of de facto standard, if any, emerges.

> Also, is it really part of simple security?

I would argue it is.  Specifically, it's a constraint on simple  
security to ensure that applications are not prevented from soliciting  
inbound flows without knowing in advance the remote addresses of their  
peers.

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

Why do you think this may be necessary?

>  ** Obsolete normative reference: RFC 4748 (Obsoleted by RFC 5378)
>
>  -- Obsolete informational reference (is this intentional?): RFC 3989
>     (Obsoleted by RFC 5189)

Thanks for catching these.


--
james woodyatt <[e-mail]>
member of technical staff, communications engineering