Re: comments on draft-ietf-v6ops-cpe-simple-security-04

[james woodyatt <[e-mail]>]

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


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