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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

James,

Eliding the points that seem to be resolved...

On 2009-04-18 08:03, james woodyatt wrote:
> On Apr 16, 2009, at 16:27, Brian E Carpenter wrote:

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

A forward ref to section 3.1 would cover it just fine.

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

Still open.

>>
>>
>> In section 2.2:
...
>> 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?

Maybe it doesn't need to be formally deprecated - just point out
that host 6to4 isn't expected to be relevant when there's an IPv6 CPE.

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

Still open.

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

Still open.


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

Still open.

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

Right, which is why I wonder whether it is a recommendation at all.
It seems more like a placeholder.

>> I fear you will need to insert the pre-RFC5378 disclaimer.
> 
> Why do you think this may be necessary?

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

Do you have permissions from those authors? If not, you need the disclaimer.

    Brian