Subject: WGLC: draft-ietf-v6ops-cpe-simple-security-10.txt

From: Fred Baker <[email-masked]>
Date: Sun, 11 Apr 2010 12:59:02 -0700

As agreed at the last IETF meeting, I am opening a two week WGLC of draft-ietf-v6ops-cpe-simple-security-10.txt. Please read the document, comment to this list on matters of substance, and send nits (spelling/grammar, word choice, sentence structure comments) to the authors.

http://www.ipinc.net/IPv4.GIF

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Apr 2010 10:13:32 +1200

I've read this version quite carefully and compared it to the
previous few versions, and I believe it is a good statement
of where we got to in the discussion.

Regards
   Brian Carpenter

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 Apr 2010 13:38:55 +0200

Le 11 avr. 2010 à 21:59, Fred Baker a écrit :

> Please read the document, comment to this list on matters of substance.

Hi all,

The document reflects to a good extent the consensus reached in Anaheim (thanks to James for all his work on this), but it can, and IMHO it should, be improved on the 2 following points:

1.
A sentence of the introduction is in part self-contradictory.
CURRENT SENTENCE: "The specific recommendations in this document are intended to promote optimal local-area network security while retaining full end-to-end transparency for users, and to highlight reasonable limitations on transparency where security considerations are deemed important."
(Strictly speaking, if "full e2e transparency" is "retained", it shouldn't be limited, even in a "reasonable" way.)
PROPOSAL: "The specific recommendations in this document specify for IPv6 a local-area network protection similar to that generally found behind IPv4 NATs. Limitations to full IPv6 end-to-end network transparency, unavoidable where this protection is supported, are minimized."
2.In the summary of section 4, the introductory sentence seems to imply that the document recommends *in general* the specified level of protection, which is beyond the intent of the consensus.
CURRENT SENTENCE: "This section collects all of the recommendations made in this document into a convenient list."
PROPOSAL: "This section collects into a convenient list all recommendations made for CPEs that support the level of local-area network protection specified in this document."

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 13 Apr 2010 12:42:22 +0200

Hi James,

After a review of what RFC 4890 says, the new section 3.2.1 on ICMPv6 needs in my understanding to be modified.

CURRENT 3.2.1 TEXT: "Recommendations for filtering ICMPv6 messages in firewall devices are described separately in [RFC4890] and apply generally to residential gateways as to any class of router.  No additional recommendations are made here, but it's important to note that Destination Unreachable and Packet Too Big errors corresponding to filtering states for all upper-layer transport protocols are important to the proper function of the Internet."

PROBLEM: 
RFC 4890 recommends that NO Destination Unreachable and NO Packet Too Big error messages be dropped (sec 4.3.1).
If the intent is that incoming DU or PTB messages that don't match any filtering state should be dropped, this should then be expressed as an *additional* recommendation. 
(If the intent is different, I have difficulty understanding it.)

PROPOSAL: "Recommendations for filtering ICMPv6 messages in firewall devices are described separately in [RFC4890] and apply to residential gateways, with the additional recommendation that incoming Destination Unreachable and  Packet Too Big error messages that don't match any filtering state should be dropped."

Accordingly, REC-12  would become:
" REC-12: IPv6 gateways SHOULD NOT forward ICMP Destination Unreachable and Packet Too Big messages containing IP headers that don't match generic upper-layer transport state 3-tuples."
(Note, besides, that since it deals with ICMP, this REC would better be placed in 3.2.1 than in 3.2.2.)

As the point raised is more than editorial, I look forward to your view on it.

Best regards,
RD

 [RD1]This sentence suggests that forwarding PTB messages corresponding to filtering states could be beyond what is imposed by RFC4890 , i.e.

could be added

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 20 Apr 2010 09:17:11 -0700

> Fred Baker wrote: 
> 
> As agreed at the last IETF meeting, I am opening a two week WGLC of 
> draft-ietf-v6ops-cpe-simple-security-10.txt. Please read the document, 
> comment to this list on matters of substance, and send nits (spelling/
> grammar, word choice, sentence structure comments) to the authors.

I realize I am late with this but I have reviewed the document and have the following comment:

The document does not explicitly mention how should IPv6 be treated by a CPE. 

Mobile IPv6 involves the use of IP-in-IP tunneling and of IPsec and IKE, all of which seems to be covered in Section 2.2. in an adequate manner:

2.2.  Internet Layer Protocols

   As virtual private networking tunnels are regarded as an unacceptably
   wide attack surface, this document recommends the DEFAULT operating
   mode for residential IPv6 simple security is to treat IP-in-IP and
   GRE tunneling protocols as opaque transport layers, i.e. inbound
   tunnel initiations are denied and outbound tunnel initiations are
   accepted.  IPsec transport and tunnel modes are explicitly secured by
   definition, so this document recommends the DEFAULT operating mode
   permit IPsec and Internet Key Exchange (IKE) flows to pass without
   filtering.

Mobile IPv6 also involves the use of the Mobility Header, which seems to be appropriately covered by the recommendation of Section 3.2.2.:

3.2.2.  Upper-layer Transport Protocols

   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.

   In general, upper-layer transport filter state records are expected
   to be created when an interior endpoint sends a packet to an exterior
   address.  The filter allocates (or reuses) a record for the duration
   of communications, with an idle timer to delete the state record when
   no further communications are detected.

   REC-10: Filter state records for generic upper-layer transport
   protocols MUST BE indexable by a 3-tuple comprising the interior node
   address, the exterior node address and the upper-layer transport
   protocol identifier.

   REC-11: Filter state records for generic upper-layer transport
   protocols MUST NOT be deleted or recycled until an idle timer not
   less than two minutes has expired without having forwarded a packet
   matching the state in some configurable amount of time.  By DEFAULT,
   the idle timer for such state records is five minutes.

However MIPv6 also relies on the use of a degenerated tunneling mechanism between a Mobile Node and its corresponds nodes. This tunneling involves the use of the Routing Header Type 2 and of the Home Address destination option, which are not covered in the document. 

In practice I believe this type of tunnel should be treated as IP-in-IP tunnels, but this is currently not the case. The issues is as follows:

Outbound packets sent in the tunnel are sent from the Mobile Node Care-of Address and with a Home Address destination option -- so it seems that there is no problem for those, although we might want to be explicit.

However inbound packets corresponding to an outbound initiated tunnel should be accepted as well (as for IP-in-IP), but these packets will be destined to the Home Address and carrying the Care-of Address in the Routing Header Type 2, so they will not be handled properly absent an explicit recommendation that the CPE tracks MIPv6 HoA/RH2 degenerated tunnels.

I believe we should cover MIPv6 adequately in this specification by adding explicit tracking of outbound initiated MIPv6 HoA/RH2 degenerated tunnels. 

[ The MEXT WG has two documents specifying firewall behavior for MIPv6 that could be used as a starting point for text to be included in this spec -- see http://tools.ietf.org/html/draft-ietf-mext-firewall-vendor-02 and http://tools.ietf.org/html/draft-ietf-mext-firewall-admin-02 ]

What do people think?

--julien

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Apr 2010 10:06:11 -0700

Thanks. On your first point, we tossed around the idea of merging it into draft-ietf-cpe-router and chose not to. This document describes an additional feature that vendors MAY build into a CPE Router.

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Apr 2010 10:43:28 -0700

> [ The MEXT WG has two documents specifying firewall behavior for MIPv6 that could be used as a starting point for text to be included in this spec -- see http://tools.ietf.org/html/draft-ietf-mext-…

This is an important technical point.  I will review those drafts and send a revision to I-D.ietf-v6ops-cpe-simple-security shortly.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 21 Apr 2010 18:33:17 +0200 (CEST)

On Tue, 20 Apr 2010, Laganier, Julien wrote:

> However MIPv6 also relies on the use of a degenerated tunneling 
> mechanism between a Mobile Node and its corresponds nodes. This 
> tunneling involves the use of the Routing Header Type 2 and of the Home 
> Address destination option, which are not covered in the document.
>
> In practice I believe this type of tunnel should be treated as IP-in-IP 
> tunnels, but this is currently not the case. The issues is as follows:
>
> Outbound packets sent in the tunnel are sent from the Mobile Node 
> Care-of Address and with a Home Address destination option -- so it 
> seems that there is no problem for those, although we might want to be 
> explicit.
>
> However inbound packets corresponding to an outbound initiated tunnel 
> should be accepted as well (as for IP-in-IP), but these packets will be 
> destined to the Home Address and carrying the Care-of Address in the 
> Routing Header Type 2, so they will not be handled properly absent an 
> explicit recommendation that the CPE tracks MIPv6 HoA/RH2 degenerated 
> tunnels.
>
> I believe we should cover MIPv6 adequately in this specification by 
> adding explicit tracking of outbound initiated MIPv6 HoA/RH2 degenerated 
> tunnels.
>
> [ The MEXT WG has two documents specifying firewall behavior for MIPv6 
> that could be used as a starting point for text to be included in this 
> spec -- see 
> http://tools.ietf.org/html/draft-ietf-mext-firewall-vendor-02 and 
> http://tools.ietf.org/html/draft-ietf-mext-firewall-admin-02 ]
>
> What do people think?

Is it still applies to "CPE simple security"?  In my opinion, vendor might 
decide implement these additional settings... 
Best Regards,

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Apr 2010 09:46:14 -0700

Mohacsi Janos wrote:
> Laganier, Julien wrote:
> > [ The MEXT WG has two documents specifying firewall behavior for
> > MIPv6 that could be used as a starting point for text to be included
> > in this spec -- see
> Is it still applies to "CPE simple security"?  In my opinion, vendor
> might decide implement these additional settings...

I do not think that recommending that a typical off-the-shelf IPv6 CPE breaks MIPv6 is an option...

--julien

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 21 Apr 2010 18:54:42 +0200 (CEST)

Hi Remi,

I feel to be asked  as a co-author of the RFC 4890.

On Tue, 13 Apr 2010, Rémi Després wrote:

> CURRENT 3.2.1 TEXT: "Recommendations for filtering ICMPv6 messages in firewall devices are described separately in
> [RFC4890] and apply generally to residential gateways as to any class of router.  No additional recommendations are made
> here, but it's important to note that Destination Unreachable and Packet Too Big errors corresponding to filtering states
> for all upper-layer transport protocols are important to the proper function of the Internet."
> 
> PROBLEM: 
> If the intent is that incoming DU or PTB messages that don't match any filtering state should be dropped, this should then
> be expressed as an *additional* recommendation. 

In the RFC 4890 we seperated the transit traffic (4.3) and the traffic 
destined (4.4) to the firewall. At that time it was written IPv6 capable 
state inspection firewalls was rare (see section 4.1) therefore we 
recommended NOT to drop transit destination unreachable and and packet too 
big errors icmpv6 packets..

As described in section 4.1 of RFC 4890:
"Depending on the capabilities of the firewall being configured, it
    may be possible for the firewall to maintain state about packets
.....
This state may allow the firewall to perform more precise
    checks based on this state, and to apply limits on the number of
    ICMPv6 packets accepted incoming or outgoing as a result of a packet
    traveling in the opposite direction.
"

So this might be defined more clearly in RFC 4890....

> 
> 
> PROPOSAL: "Recommendations for filtering ICMPv6 messages in firewall devices are described separately in [RFC4890] and
> apply to residential gateways, with the additional recommendation that incoming Destination Unreachable and  Packet Too Big
> error messages that don't match any filtering state should be dropped."

This way it is more understandable....

Best Regards,

 		Janos Mohacsi

---

From: Rémi Després <[email-masked]>
Date: Wed, 21 Apr 2010 19:05:49 +0200

Le 21 avr. 2010 à 18:54, Mohacsi Janos a écrit :

> ...

I am glad it helps.
Best regards.
RD

---

From: Timothy Baldwin <[email-masked]>
Date: Thu, 22 Apr 2010 01:10:21 +0100

Fred Baker wrote:

> comment to this list on matters of substance, and send nits
> (spelling/grammar, word choice, sentence structure comments) to the
> authors.

Section 3.4. Passive Listeners

Teredo could be mentioned alongside STUN as a means of transversing IPv4 
NAT, it is significant in that a IPv6 application may have better 
connectivity behind an IPv4 NAT than behind simple security.

"something similar to NAT-PMP and UPnP-IGD but without actually supporting 
NAT needs to be deployed."

It doesn't need to be protocol to configure the gateway, any solution that 
allows passive listeners to opt in will suffice. Since there is no 
requirement to protect the host IP stack (plenty of other holes) a packet 
mangling scheme could used. An idea:

Instead of dropping, and possibly sending an ICMP Destination Unreachable 
Message, a gateway should instead insert a Firewall header intp the packet, 
if there is Hop-by-Hop Options header the Firewall header should be inserted 
immediately after the Hop-by-Hop Options header, otherwise the Firewall 
header must be inserted immediately after the IPv6 header. The Next Header 
value for a Firewall Header is TBD.

+---------------+----------------------------------------+
|  Next Header  |  Modified EUI-64 of gateway (8 bytes)  |
+---------------+----------------------------------------+

If the forwarded packet results in a ICMP Error packet, the gateway MUST 
remove any Firewall header that it inserted. If the packet is a Packet Too 
Big Message the MTU value must be reduced by 9, to account for the size of 
the Firewall header. If the packet is a Parameter Problem Message the 
pointer must be adjusted accordingly if it does not refer to the Firewall 
header being removed, if it does the packet must be converted to a ICMP 
Destination Unreachable Message, with a code of 1 - administratively 
prohibited.

---

From: james woodyatt <[email-masked]>
Date: Thu, 22 Apr 2010 12:16:36 -0700

> Message, a gateway should instead insert a Firewall header intp the packet, 

The design team considered and rejected this category of ideas.  Marking unsolicited and insecure traffic before forwarding it into the interior defeats the intended purpose of IPv6 Simple Security, which is *explicitly* to block it entirely.  There has been much working group discussion already on this topic, and the sense of the working group as I understand it is that the distinction between blocking and marking is a feature of this draft.  It's quite deliberate.

I believe proposals to mark instead of block to be now out of scope for I-D.ietf-v6op-cpe-simple-security.  I think a better place for that discussion would be in the context of I-D.vyncke-advanced-ipv6-security, which is properly positioned as an alternative to this draft.

> connectivity behind an IPv4 NAT than behind simple security.

I'd rather not explicitly encourage the use of Teredo in a non-transitional mode.  Not without seeing the appropriate revisions to the Teredo specification published as Standard Track to make it clear that Teredo is now expected to be used in non-transitional networks for the purpose of improving transparency in the face of IPv6 simple security filtering.  I don't see that happening.  Do you?

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 27 Apr 2010 12:30:57 -0600

FWIW I gave this a read and it looked pretty good to me. 

> http://www.ipinc.net/IPv4.GIF

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html