everyone--
I personally invited Keith Moore to comment on the subject of draft-ietf-v6ops-cpe-simple-security, and he graciously sent me the following response, but I think he inadvertently neglected to Cc the working group. [I'm including the entire text of his comments.]
My comments are included inline.
On Mar 27, 2009, at 13:50, Keith Moore wrote:
this is from a single pass through the document, and I'll admit to not
being well-focused when trying to review a document while sitting in
WG meetings. but these are the notes I took while reading it:
section 2, middle of page 4:
It should be noted that NAT for IPv6 is both strictly forbidden by
the standards documents and strongly deprecated by Internet
operators.
really? or is this just wishful thinking?
You're right. I confess to being poorly informed when I wrote that. I've since learned that no such prohibition, in fact, exists.
section 2.1:
In particular, packets with end-to-
end network security and routing extension headers for mobility are
expected to pass Internet gateways freely.
interesting. so as an application developer, if I want a protocol to
go through a firewall by default, I can just wrap it in IPsec or mobileIP?
Yes.
(and can I do this without actually implementing IPsec or mobileIP?)
Yes. There is no way for the residential gateway to test if your IPsec or MIP6 implementation complies with the standard. For IPsec, there just simply no way to know whether the SA really exists and/or what security parameters were negotiated, if any. For MIP6, I admit, the design team may not have considered all the angles. It's possible that a gateway might be able to impose some sanity on mobility that we didn't consider.
I'm open to suggestions.
section 2.2:
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].
mumble. the fact that a gateway supports IPv6 access of some kind doesn't
mean that the IPv6 is enabled or working. so I don't think the gateway
should block Teredo by default. it seems like the thing to do is to
impose the same filters on Teredo traffic that are imposed on native IPv6
traffic.
This isn't an oversight, and it was the subject of some debate on the working group list at the time, so I'd invite you to open further debate in the working group on the topic.
The design team interpreted the Teredo automatic sunset provision a bit broadly, I'll admit, but we thought it was important to discourage actively the use of Teredo when a more appropriate IPv6 service is *configured*. If Teredo would provide better service than the configured service, then we thought it would be reasonable to require the administrator to change the configuration to disable the default IPv6 service.
section 3.1:
R3: Packets bearing deprecated extension headers prior to their first
upper-layer-protocol header MUST NOT be forwarded or transmitted on
any interface. In particular, all packets with routing extension
header type 0 [RFC2460] preceding the first upper-layer-protocol
header MUST NOT be forwarded.
I agree with the intent, but have an issue with the way that this is
worded. The problem is that the set of deprecated headers can change
over time, causing a previously conforming implementation to become
non-conforming. Easiest fix is to make the first MUST NOT into a SHOULD
NOT. (It wouldn't hurt to add an explanation as to why it's a SHOULD NOT.)
The latter MUST NOT can stay as is.
An excellent suggestion.
R4: Outbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header does not have a unicast prefix assigned for
use by globally reachable nodes on the interior network.
Again, (mostly) agree with the intent, have a problem with the way it's
stated. How does the gateway reliably know whether the prefix is "assigned
for use by globally reachable nodes on the interior network"? What do
you mean by "assigned for use ..."? Are you talking about an IANA assignment
or a local assignment (say of a ULA)? Is this a requirement that might
change over time as IANA assigns new prefixes? Or something that needs to
be configured at the gateway?
At the least, I think the wording is ambiguous here. If you mean an IANA
assignment, say so, and make it a SHOULD NOT because it can change over time.
Hmm. This could use clarification, yes. What I mean by assigned: either manually or automatically configured. Would it make more sense if I just changed the word "assigned" to "configured?"
R4: Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for use
by globally reachable nodes on the interior network.
*** note: there are two R4s.
Yuck. There are.
(does this thwart Mobile IPv6?)
I'll check and fix if so.
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.
Seems ambiguous. How does the router know if the packet is crossing a
ULA scope boundary? It's not as if a ULA is inherently confined to the
"inside" of the router. Don't assume that the outside of the router is
the public IPv6 network.
Also the first sentence seems to give the router
license to arbitrarily discard packets just because the packet uses a
ULA. This needs to be configurable and the router needs to honor its
configuration. It might be that a reasonable default would be to drop
such packets (on the theory that most consumers won't be using ULAs and
those that do will know enough to enable them) but I can't confidently
state that for all use cases. If some ISP wants to distribute CPE boxes
that make some use of ULAs, should this document preclude that?
Maybe: a) packets with src/dest ULA addresses SHOULD be discarded by default
b) this behavior MUST be configurable
but as for how best to configure it, I'm not sure. maybe be able to explicitly
permit src or dest ULAs that match any of a list of prefix/netmasks.
Good grief, you're right. That was badly worded. I think you captured the intent. I'll rewrite. Remember, we're talking about residential gateway routers attached to a service provider uplink. Other routers in a routed residential network may need to have different behaviors, but it seems like a good default is to keep the ULAs confined to residential networks. Absolutely, this MUST be a configurable option. I think it ought to be sufficient to allow the user to configure their gateway not to confine ULA addresses.
R6: By DEFAULT, inbound non-recursive DNS queries received on
exterior interfaces MUST NOT be processed by any integrated DNS proxy
resolving server.
emphatically agree. (I'd like to make similar restriction for outbound,
as I've lost way too much hair due to broken DNS proxies in SOHO gateways.)
In general, interception proxies are evil and should not be used.
section 3.2.1:
Residential IPv6 gateways are not expected to prohibit the use of
applications to be developed using future upper-layer transport
protocols. In particular, transport protocols not otherwise
discussed in subsequent sections of this document are expected to be
treated consistently, i.e. as having connection-free semantics and no
special requirements to inspect the transport headers.
This is interesting. I understand that you're trying to permit deployment
of new transport protocols, but from a security perspective I don't know
why an unknown transport protocol should get less filtering than that for
UDP. So I'm a bit uneasy with this text but I don't know how to tweak it
to make it better.
I do think there's a need to be able to configure the router to explicitly
pass any transport protocol.
***
In general about firewall state - if the firewall is colocated with NAT,
you want the lifetime of the firewall state associated with a flow to be
the same as the lifetime of the NAT binding associated with the flow.
That might seem obvious but I don't think it really is.
section 3.2.3:
R18: Where an IPv6 prefix is advertised on an interior interface
alongside an IPv4 private address [RFC1918] and IPv4 Internet service
is provided with NAT [RFC4787], the Teredo qualification procedure
(see section 5.2.1 and 5.2.2 of [RFC4380]) for clients in the
interior MUST be prohibited by the IPv4/NAT stateful filter. This
SHOULD be done by blocking outbound UDP initiations to port 3544, the
port reserved by IANA for Teredo servers.
- seems like the MUST should refer to the default behavior. it should be
possible to override it.
See above remarks. This seems a question worth asking the working group.
- are the criteria correct? What does the IPv4 private address have to
do with it?
I suppose the phrase "alongside an IPv4 private address [RFC1918]" is useless verbiage.
does the IPv6 prefix have to be advertised by the same
gateway that implements the IPv4 NAT, or can it be advertised elsewhere?
what if that prefix is not a global prefix but instead a ULA that
presumably isn't globally routeable?
Ah, yes. The intent here could be more clear.
- again it seems like the thing to do is not to block Teredo, but impose
the same filtering for Teredo that is imposed for native IPv6.
We considered that. I wonder what the sense of the working group is now.
***
I'm thinking that maybe every rule should be stated as follows:
- what's the default behavior? MUST or SHOULD?
- to what extent, and what degree of granularity, is the gateway required
to make this behavior configurable?
***
I'm also thinking there's a need for balance between default IPv4
behavior and default IPv6 behavior. We should not favor IPv4 over IPv6.
Nor should IPv6 be seen as a way to bypass IPv4 restrictions, unless there's
a technical justification for it (e.g. it's much harder to do port scanning
in IPv6 because the address space is sparse, so countermeasures for IPv4
might not be appropriate for IPv6)
Down this road lies a quagmire of trouble related to discussions that seem to be lying dormant in the wake of RFC 4864.
section 3.2.5:
Residential IPv6 gateways are not expected to prohibit the use of
virtual private networks in residential usage scenarios.
R23: In their DEFAULT operating mode, IPv6 gateways MUST NOT prohibit
the forwarding, to and from legitimate node addresses, with upper
layer protocol of type IP version 6, and SHOULD NOT prohibit the
forwarding of other tunneled networking protocols commonly used for
virtual private networking, e.g. IP version 4, Generic Routing
Encapsulation, etcetera.
For IP-in-IP tunneling, should the default restrictions on the inner packet
be the same as the restrictions on outer layer packet?
The design team considered that and decided it was unnecessary. We regarded the establishment of a tunnel, even by manual configuration, as morally equivalent to the solicitation of traffic through the tunnel, and therefore not subject to the simple security policy intended to block unsolicited flows.
section 3.3.1:
Peer-to-peer applications use an alternate method of connection
initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse
stateful filters. In the simultaneous-open mode of operation, both
peers send SYN packets for the same TCP connection.
I'd say "Some peer-to-peer applications..."
Okay.
I'm glad you mention simultaneous open, though I'm not sure how it affects
firewall operation. The firewall is still not going to permit an inbound
SYN packet unless it has first seen an outbound SYN packet. I guess the
firewall should not block an inbound SYN packet if it has recently seen an
outbound SYN packet for the same flow.
It is possible to reconstruct enough of the state of a TCP connection
to allow forwarding between an interior and exterior node even when
the filter starts operating after TCP enters the established state.
In this case, because the filter has not seen the TCP window-scale
option, it is not possible for the filter to enforce the TCP window
invariant by dropping out-of-window segments.
R25: The TCP window invariant MUST NOT be enforced on connections for
which the filter did not detect whether the window-scale option (see
[RFC1323]) was sent in the 3-way handshake or simultaneous open.
Mumble. I think you're talking about how the gateway should handle
flows that were already present (or may have already been present) before
a filter was imposed, and that the treatment of this topic seems a lot broader
than dealing with TCP window negotiation. e.g. is there a requirement that
the firewall permit inbound packets on flows for which it didn't see the
outgoing SYN because the filter was enabled after the SYN was sent?
This requirement was inserted because we wanted to be explicit about making sure that loose-state matching for TCP isn't broken by buggy window scale tracking and sequence number modulation.
(and for that matter, can the gateway reasonably assume it is the only
path between the endpoints?)
Yes, this is an assumption about simple residential gateways. We do not consider multihomed residential networks.
A stateful filter can allow an existing state record to be reused by
an externally initiated connection if its security policy permits.
Several different policies are possible as described in "Network
Address Translation (NAT) Behavioral Requirements for Unicast UDP
[RFC4787] and extended in "NAT Behaviorial Requirements for TCP"
[RFC5382].
R26: If application transparency is most important, then a stateful
packet filter SHOULD have "Endpoint independent filter" behavior for
TCP. If a more stringent filtering behavior is most important, then
a filter SHOULD have "Address dependent filtering" behavior. The
filtering behavior MAY be an option configurable by the network
administrator, and it MAY be independent of the filtering behavior
for UDP and other protocols.
I think the requirement should be stronger:
MUST implement endpoint independent filtering and this MUST be the default.
MAY implement address dependent filtering and this MUST NOT be the default.
I would agree with you, but I don't know what the rest of the working group thinks. This language came from the BEHAVE drafts for TCP, and I don't remember it being terribly controversial in the design team discussions. Perhaps the working group feels differently than we do.
address dependent filtering breaks applications.
I know. Some people like that. It breaks malicious applications.
R27: A gateway MUST NOT signal an error for an unsolicited inbound
SYN packet for at least 6 seconds after the packet is received. If
during this interval the gateway receives and forwards an outbound
SYN for the connection, then the gateway MUST discard the original
unsolicited inbound SYN packet without signaling an error.
Otherwise, the gateway SHOULD send an ICMP Destination Unreachable
error, code 1 (administratively prohibited) for the original SYN--
unless sending any response violates the security policy of the
network administrator.
I think that gateways MUST send ICMP destination unreachable by default,
MUST wait at least 6 seconds before sending it (and abandon sending it
if it's seen a SYN or SYN-ACK in the other direction) and MAY have an
option to disable sending ICMP unreachable.
Agree. This language should be cleaned up that way.
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.
I really think we need an IETF standard for this, and it needs to work
with both NATs and firewalls.
I'm less convinced the need for this is urgent, and I disagree that we need one protocol that works with both translators and filters. For IPv6 translators, e.g. NAT64, I'm beginning to think that what we really need is to resurrect RSIP. For IPv6 stateful filters, like CPE simple security, I proposed a method: ALD. A reference to it is in the draft. (That draft has quietly expired, because I've been sorta hoping the need for it would wither away, but if that's yet more of my trademark wishful thinking, I'll drag myself back into revising it.)