[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 <jhw@apple.com>
member of technical staff, communications engineering