Subject: Fwd: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03

From: Fred Baker <[email-masked]>
Date: Sun, 24 Aug 2008 04:23:42 -0700

Forwarding comments...

Begin forwarded message:

> From: Mark Smith <[email-masked]>
> Date: August 24, 2008 4:15:53 AM PDT
> To: [email-masked], v6ops-residential-cpe-design- 
> [email-masked]
> Subject: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03
>
> Hi,
>
> I've finally found a bit of time to start having a read through the 03
> version of this draft. I haven't read through all of it yet, however
> here are some starting suggestions:
>
> 2.  Overview
>
> Change "requires" to "provides", just to continue to emphasise a bit
> that the statefulness of NAT wasn't specifically designed into it:
>
> "Only the perceived security benefits associated with stateful packet
> filtering, which NAT (requires|*provides*) as a side effect, are
> thought relevant in the IPv6 residential usage scenario."
>
>
> 2.2.  Internet Layer Protocols
>
> "Therefore, this document recommends the DEFAULT operating mode for
> residential IPv6 simple security is to permit all virtual private
> networking tunnel protocols to pass through the stateful filtering
> function.  These include IPsec transport and tunnel modes as well as
> other IP-in-IP protocols."
>
> Would it be better to restrict this to authenticated tunnelling
> protocols? Wrapping a malicious packet inside a GRE or IP packet and
> having the CPE blindly forward it would seem to me to be a really
> simple and easy way to bypass all the security mechanisms that this
> draft is defining.
>
> Authenticated protocols could still expose hosts to probing e.g.
> probing a non-IPsec enabled host via IKE, which the CPE would
> forward unrestricted, could generate an ICMPv6 Port Unreachable,
> indicating a host's presence. Maybe the residential CPE should drop
> these ICMPv6 messages in the outbound direction, hiding hosts that  
> don't
> support the tunnelling method being requested from these sorts of
> probes?
>
> A few thoughts related to general tunnel security. Is it appropriate  
> for
> this draft to document that traffic arriving encapsulated should not
> automatically be trusted, and therefore should also have firewalling
> applied to it by the receiving host, after decapsulation? If the end
> user has chosen to use a clear text tunnel encapsulation method e.g.
> GRE, would there be any value in specifying that the CPE MAY inspect  
> the
> interior traffic carried within the tunnel? Limiting the number of
> encapsulation headers on a packet would also probably be something to
> define in this case. IOW, if the CPE can inspect traffic, even though
> it is encapsulated inside a tunnel, can we recommend that it should?
>
> "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."
> suggest to insert:
>
> ", excepting when the Residential Gateway is also acting as a VPN
> tunnel end-point. In this case, traffic must not be forwarded toward
> multicast destinations that are not known to be at the remote end of
> the pre-established or prior-configured on-demand tunnel(s)."
>
> "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."
>
> similar to above, suggest to insert:
>
> ", excepting when the Residential Gateway is also acting as a VPN
> tunnel end-point. In this case, traffic must not be forwarded to
> unicast destinations that are not known to be at the remote end of the
> pre-established or prior-configured on-demand tunnel(s)."
>
>  "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."
>
> suggest to add tunnel end-point text as per above.
>
>
> "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."
>
> suggest to add tunnel end-point text as per above.
>
>
> That's it for the moment, I'll continue reading through it over the
> next few days.
>
> Regards,
> Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 24 Aug 2008 20:45:53 +0930

Hi,

2.  Overview

these ICMPv6 messages in the outbound direction, hiding hosts that don't

A few thoughts related to general tunnel security. Is it appropriate for
GRE, would there be any value in specifying that the CPE MAY inspect the

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

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Aug 2008 09:04:40 +1200

Hi Mark,

On 2008-08-24 23:15, Mark Smith wrote:
...
> simple and easy way to bypass all the security mechanisms that this

I would object to that. That amounts to default-deny for all
the commonly used ways of bypassing ISPs that don't support
IPv6, and that would be a Bad Thing.

I think a recommendation that CPEs should document and warn about
such risks is a good idea, rather in the manner of personal
firewalls that alert you the first time you try to tunnel out
with Protocol 41, but remember when you click OK. Can we recommend
default-warn rather than either default-deny or default-allow?

...
> this draft to document...

How about referring to draft-ietf-v6ops-tunnel-security-concerns?
We should probably concentrate those issues in one place.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 24 Aug 2008 19:38:49 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Sunday, August 24, 2008 2:05 PM
> To: Mark Smith
> Cc: [email-masked]; IPv6 Operations
> Subject: Re: Some suggestions for 
> draft-ietf-v6ops-cpe-simple-security-03
> 
> Hi Mark,
> 

You're saying that the Simple CPE Security document is not intended
to provide security, but rather intended to provide a way to receive
unsolicited IPv6 traffic through non-IPv6-capable SPs?

-d

> > A few thoughts related to general tunnel security. Is it 
> > appropriate for this draft to document...
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Aug 2008 16:22:41 +1200

> unsolicited IPv6 traffic through non-IPv6-capable SPs?

If a host behind the CPE chooses to set up an IPv6 tunnel to
an IPv6-supporting ISP, I don't see that the tunnel is anybody's
business but the host's. So yes, in that case I think the CPE
should step back, because the host *is* soliciting incoming
packets.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 24 Aug 2008 22:23:02 -0700

> should step back, because the host *is* soliciting incoming

But in that case, the host behind the CPE initiated the 
communication to the tunnel.  For that to work, I do not
believe it requires the CPE to allow unsolicited *incoming* 
traffic from the Internet (as currently written in 
draft-ietf-v6ops-cpe-simple-security-03.txt R19, R20, and R21).

-d

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 Aug 2008 21:08:15 +0930

Hi Brian,

On Mon, 25 Aug 2008 09:04:40 +1200

> IPv6, and that would be a Bad Thing.

I've been reading this draft from the perspective that it was only
describing native IPv6 operation within CPE, not IPv6 over IPv4
transition methods as well, so my comments were from the point of view
of the exterior tunnel header being IPv6. In that tunnelled-over-IPv6
scenario, I'd still argue for only allowing authenticated tunnelled
protocols to transit the CPE without any stateful inspection.

OTOH, if the draft is also covering firewalling requirements to allow
IPv6 over IPv4, then I support what you're saying for that scenario. If
the draft is covering IPv6 over IPv4 methods and therefore the
consequent IPv4 firewalling requirements, then I think that needs to be
made more obvious in the draft.

> We should probably concentrate those issues in one place.

I certainly agree, I haven't yet come across that draft. I'll have a
look at it.

Thanks,
Mark.

---

From: [email-masked]
Date: Mon, 25 Aug 2008 11:14:27 -0600

Fred Baker writes: 

>> To: [email-masked], v6ops-residential-cpe-design- [email-masked]

Problem with the text is that NAT <> security, this is why it is not in v6.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2008 09:01:23 +1200

> draft-ietf-v6ops-cpe-simple-security-03.txt R19, R20, and R21).

How does it know that a Protocol 41 packet is unsolicited?
An IPv4 router takes no part in IPv6 tunnel setup. Either it
allows Protocol 41 or it doesn't, as far as I can see.

Note, I'm not talking about *-in-IPv6 tunnels.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Aug 2008 14:12:43 -0700

> How does it know that a Protocol 41 packet is unsolicited?

The same way it knows a non-protocol 41 packet is solicited: the
host sends a packet first -- the host being protected by the CPE 
doing Simple Security.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2008 09:59:31 +1200

> host sends a packet first -- the host being protected by the CPE 

How does that work if Host A (behind the CPE) has informed Host X
(outside) of the tunneled address of Host B (also behind the CPE)?
In other words A has solicited X to send a packet to B.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Aug 2008 15:07:33 -0700

> In other words A has solicited X to send a packet to B.

The network diagram would look like this, I believe:

              +-----+
    Host A ---+     |
              + CPE +--------- Internet ------  Host X
    Host B ---+     |
              +-----+

If the CPE is providing security -- as this draft is titled -- the
traffic from X to B would be blocked.  

To permit such traffic, B would need a way to tell the CPE to allow 
such traffic from X (or to allow arbitrary traffic from any host 
on the Internet).  This is described in Section 3.4 of 
draft-ietf-v6ops-cpe-simple-security-03 (where James mentions 
Apple's ALD") but, to my knowledge, has not received much 
attention and I do not know if it has working group consensus.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2008 10:37:36 +1200

> attention and I do not know if it has working group consensus.

The thing is that it can't meet any reasonable definition of
'simple'...

But blocking tunnels by default, although it's simple, also
blocks innovation. That worries me.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Aug 2008 17:11:13 -0700

> blocks innovation. That worries me.

Would your worry go away if the IETF initiated a standards effort around
something like Apple's ALD (draft-woodyatt-ald-03.txt)?

-d

---

From: Truman Boyes <[email-masked]>
Date: Mon, 25 Aug 2008 20:23:58 -0400

> blocks innovation. That worries me.

I agree with this stance. Blocking tunnels, although possibly more  
secure is going to make it very difficult to solve real world  
problems. We have enough trouble today with IPv4 Port forwarding in  
CPEs and the fact that some devices do not by default pass VPN  
traffic. I believe internal to external tunnel flow/solicitation  
should be permitted by default.

Truman

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Aug 2008 17:29:47 -0700

> should be permitted by default.

Internalt to external is permitted, by default, in the current document.

We are discussing external to internal.  

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2008 12:57:30 +1200

> something like Apple's ALD (draft-woodyatt-ald-03.txt)?

I believe that something like that is needed.

   Brian

P.S. I am about to disappear on vacation until Sept. 15.

---

From: Gert Doering <[email-masked]>
Date: Tue, 26 Aug 2008 13:49:19 +0200

Hi,

> We are discussing external to internal.  

What is "internal to external" is inevitably "external to internal" to
someone else.

How do you solve "tunneling is permitted if solicited from the inside" for 
the

  Host A --- CPE A ----[Internet]---- CBE B --- Host B

case?

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Aug 2008 10:18:58 -0700

> From: Gert Doering [mailto:[email-masked]] 
> Sent: Tuesday, August 26, 2008 4:49 AM
> To: Dan Wing
> Cc: 'Truman Boyes'; 'Brian E Carpenter'; 'Mark Smith'; 
> [email-masked]; 'IPv6 Operations'
> How do you solve "tunneling is permitted if solicited from 
> the inside" for the
> 

The host (A and/or B) have to tell the CPE that they want the communication
to occur.

Let me ask the question the other way:  how do you prevent a mis-configured
application on Host A or Host B from being accessed from the Internet?  It is
my understanding such protection ('simple security') is the primary goal of
this working group document.

-d

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Aug 2008 10:06:40 +0200

> I believe that something like that is needed.

I also support that remote control of packet filtering should be 
standardized.

IMO, its scope should cover both:
- CPE control by hosts
- control of ISP provided filtering devices by customer sites.

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Aug 2008 10:51:04 +0200

>   Host A --- CPE A ----[Internet]---- CBE B --- Host B

In my understanding, there is no ambiguity.

Internal or External is defined only for a two-sided device the place of 
which is specified in the global Internet:
- External is toward the core (or the root) of the routing hierarchy, 
i.e. the side of the device where the 0/0 route goes (the "rest of the 
world").
- Internal is the opposite. It is toward the periphery (or the leaves) 
of the routing hierarchy, where the 0/0 route doesn't go.

Thus:
- A is internal to CPE A.
- CPE B and B are external to CPE A.
- A and CPE A are external to CPE B.
- B is internal to CPE B

Filtering control, if not dministrative, should always come from the 
internal side (from A to CPA A, from B to CPE B).

RD

---

From: Gert Doering <[email-masked]>
Date: Wed, 27 Aug 2008 11:12:21 +0200

Hi,

> In my understanding, there is no ambiguity.
[..]
> internal side (from A to CPE A, from B to CPE B).

Staying in the context of the original discussion: if you want to permit
tunneled packets for IPv6 (or other) purposes, but at the same time insist
that "packets must be solicited from the internal side", how do you make
the scenario above work?

That was my whole point.  The argument "the CPE will know what the host
wants to receive" doesn't work for enduser-to-enduser traffic, unless
you have a signalling mechanism.  Or you just permit tunnels.

Gert Doering
        -- NetMaster

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 27 Aug 2008 11:43:46 +0200

On Wed, 27 Aug 2008 10:06:40 +0200, Rémi Després <[email-masked]>

>>> Would your worry go away if the IETF initiated a standards effort

>> around something like Apple's ALD (draft-woodyatt-ald-03.txt)?

>> I believe that something like that is needed.

Me too.

> - control of ISP provided filtering devices by customer sites.

I have to disagree. An ISP is not supposed to do filtering in the first

place.

Also, in real life, filtering by ISP is typically one of:

- NAT contingency, in which case it cannot be controlled directly,

- not meant to be controlled by the user

  (e.g. blocking SMTP, NetBIOS, or other protocols, spoof protection...)

I dare stress that NAT control is _not_ the same thing as filtering

control.

-- 

Rémi Denis-Courmont

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Aug 2008 19:47:13 +0930

On Mon, 25 Aug 2008 17:29:47 -0700

> We are discussing external to internal.  

external to interal what? IPv6 in IPv4, IPv6 in GRE in IPv4, IPv6 in
IPsec in IPv4, IPv6 in L2TP in IPv4, IPv6 in IPv6, IPv6 in GRE in IPv6
etc. etc.

The draft seems to be limited to specifying IPv6 only CPE
security functionality. My comments about limiting uninspected
inbound tunnel encapsuluation to authenticated protocols were only
regarding IPv6 in IPv6 (or IPsec over IPv6, or GRE over IPv6)
tunneling. No IPv4 involved or seen.

All the discussion that has occured since seems to be discussing IPv6
over IPv4, and IMHO that is not within scope the way the draft
is currently written.

So it seems to me that before this discussion goes on too much more, we
should agree on exactly what we're talking about and what we understand
the draft is to cover. Namely, is it:

* IPv6 only CPE security functionality
* Native IPv6 CPE security, plus IPv4 security/functionality
requirements to support IPv6 transition via IPv4 tunnelling
* Native IPv6, plus IPv4 security/functionality requirements to support
IPv6 transition, and IPv4 security in both IPv4 NAT and Non-NAT
scenarios.

I certainly think the last point is out of scope. However, if the
second one is the scope, then I think the draft will have to deal with
 and specify all the various IPv4 NAT/NAPT/No NAT tunnelling scenarios
and security issues related to tunnelling IPv6 over IPv4.

Regards,
Mark.

---

From: <[email-masked]>
Date: Wed, 27 Aug 2008 13:46:34 +0300

>  (e.g. blocking SMTP, NetBIOS, or other protocols, spoof 

In cellular environments filtering of the downlink carbage to increase battery lifetime of handhelds is an important function.

However, if the firewall is there to save batteries and not to enforce any special policies, it might be more willing to be controlled?

Best regards,

	Teemu

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Aug 2008 13:48:23 +0200

> However, if the firewall is there to save batteries and not to enforce any special policies, it might be more willing to be controlled?

I support this last point.

Indeed, if a cell phone would open just a few (address,port) couples, 
possibly none, for incoming connections, and would have this enforced by 
its service provider, it would be much better protected against battery 
exhaustion due to malevolent (address,port) scanning.

A protocol that at least achieves this level of protection is IMO needed.

Regards,

RD

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 27 Aug 2008 14:21:23 +0200

On Wed, 27 Aug 2008 13:46:34 +0300, <[email-masked]> wrote:

> In cellular environments filtering of the downlink carbage to increase

> battery lifetime of handhelds is an important function.

> However, if the firewall is there to save batteries and not to enforce

any

> special policies, it might be more willing to be controlled?

Hmm, that's right. I assume in most cases, statefull firewall is used

however, with its advantage (it does not need any new signaling protocol)

and its well-known limitations.

I just fear that "cross-domain" control brings intractable security vs

deployment constraints onto the control protocol. I hope we can stick to

simple return-routability checks for ALD or whatever it turns into. If you

ask me, this protocol is dead on arrival if it requires x509 or another

strong authentication mechanism, that breaks the "zeroconf" property of ALD

as it currently is specified.

-- 

Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 27 Aug 2008 14:27:09 +0200

On Wed, 27 Aug 2008 13:48:23 +0200, Rémi Després <[email-masked]>

> exhaustion due to malevolent (address,port) scanning.

Well, that's a double edged sword.

The fact that most 3G IP access are currently heavily firewalled forces end

devices into sending frequent keep-alive packets. That affects the battery

lifetime VERY BADLY. In practice, no firewall would damage battery lifetime

_much_less_ than a statefull firewall.

Discarding a few bogus _received_ packets is much less current-expensive

than _sending_ frequent keep-alive packets.

-- 

Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Aug 2008 07:47:05 -0700

> Sent: Wednesday, August 27, 2008 2:12 AM
> To: Rémi Després
> Cc: Gert Doering; Dan Wing; 'Truman Boyes'; 'Brian E 
> Carpenter'; 'Mark Smith'; [email-masked]; 'IPv6 Operations'
> the inside" for 
> you have a signalling mechanism.  

Right - we need a signaling mechanism (something like Apple's
ALD, which is described in the draft).

> Or you just permit tunnels.

I don't understand why a tunnel should get an excemption from 
Simple Security.  A tunnel can be used as an attack vector as
easily as native protocols (Netbios, FTP, HTTP, or NFS server).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Aug 2008 07:54:20 -0700

> From: Mark Smith 
> [mailto:[email-masked]] 
> Sent: Wednesday, August 27, 2008 3:17 AM
> To: Dan Wing
> Cc: 'Truman Boyes'; 'Brian E Carpenter'; [email-masked]; 'IPv6 
> Operations'
> Subject: But are we talking IPv6 only? That's how I read the 
> draft. (Re: Some suggestions for 
> draft-ietf-v6ops-cpe-simple-security-03)
> 
> 
> external to interal what?

External to network that the CPE, providing Simple Security, is
protecting.

> IPv6 in IPv4, IPv6 in GRE in IPv4, IPv6 in

I, at least, am not thinking of anything running over v4 in 
regards to v6ops-cpe-simple-security.

The only exception for tunnels that I see in the draft is for
tunnels running over v6, in requirement R22:

   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.

I don't see any exception, or discussion, of v4 tunnels except for
Teredo -- and the draft recommends those be blocked.

> I certainly think the last point is out of scope.

And the draft has no requirement for that last point, except to
break Teredo (requirement R18).

> However, if the

-d

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Aug 2008 12:01:35 -0700

> made more obvious in the draft.

Point noted.  It needs to be more obvious in the draft.

> On Mon, 25 Aug 2008 09:04:40 +1200 Brian E Carpenter <[email-masked] 
> > wrote:
>

I plan to do that when I import the Teredo heuristic from its earlier  
[expired] draft.  A new draft should be available soon (end of the  
week?) I hope.

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Aug 2008 12:09:43 -0700

On Aug 27, 2008, at 01:06, Rémi Després wrote:
>>> around

I must chime in here and repeat for the record that ALD is most  
emphatically NOT a protocol for enabling hosts to control filtering  
devices.  I took Great Pains to specify it as a protocol for filtering  
devices to learn about interior applications that are soliciting  
inbound traffic from arbitrary exterior nodes regardless of their  
remote address.

Please please please I am VERY resistant to positioning ALD as a  
method for nodes to use in "controlling" firewall devices.

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Aug 2008 12:12:28 -0700

> requirements to support IPv6 transition via IPv4 tunnelling

It was my understanding that this is the proper scope, not the  
alternatives you mentioned.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Aug 2008 12:54:50 -0700

> method for nodes to use in "controlling" firewall devices.

Er, it seems the same to me.  Are you just saying that the interior
host is not necessarily *overriding* the filtering device's rules?
If that's what you're saying, I agree, and I think that's fine.

-d

---

From: Mark Smith <[email-masked]>
Date: Thu, 28 Aug 2008 07:12:00 +0930

Hi James,

On Wed, 27 Aug 2008 12:12:28 -0700

> alternatives you mentioned.

In that case, I'd still strongly suggest limiting the IPv6 in IPv6
tunnel support to authenticated protocols only. Bypassing the CPE
security using a linux box (or anything else that supports end-user
manually configured tunnels, on which the user has admin priviledges)
will be as simple as something like this (syntax probably not right ,
but that's because I've got a few minutes before I need to get ready for
work):

# ip -6 tunnel add v6cpe-bypass  remote 2001:<public node address>
# nmap -e v6cpe-bypass

As I understand the current draft, this would completely bypass any and
all of the IPv6 security mechanisms in the device - and because it's so
easy to do, anybody who wants to make an attempt at attacking an
end-node will do so this way. Only permitting inbound authenticated
tunneling protocols like IPsec, l2tp or pptp would easily defeat that.

Regards,
Mark.

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Aug 2008 15:10:09 -0700

On Aug 27, 2008, at 12:54, Dan Wing wrote:
> [I wrote:]
>> devices.  I took Great Pains to specify it as a protocol for  
>> filtering devices to learn about interior applications that are  
>> soliciting inbound traffic from arbitrary exterior nodes regardless  
>> of their remote address.
>>

I'm actually making a somewhat stronger statement.

I'm saying that the Purpose of ALD is *NOT* for interior nodes to  
control their corresponding states in filtering middleboxes, but  
rather for middleboxes to learn about state at interior nodes relevant  
for network filtering.  The design of ALD is a reflection of this  
statement of purpose, which is why it defines no mechanism for  
informing endpoint nodes whether and/or why not filtering rules have  
changed as a result of the notifications they send.

I don't mean to sound like I'm picking nits, but I really do think  
it's a big mistake to formulate the problem statement around a  
perceived need for endpoint nodes to "control" the state of  
middleboxes.  I contend there is no such need.  There is only a need  
for filtering middleboxes to be better aware of endpoint state so that  
they do not intrude on network transparency unnecessarily, i.e. when  
security policy does not require it.

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Aug 2008 15:20:37 -0700

On Aug 27, 2008, at 14:42, Mark Smith wrote:
> Only permitting inbound authenticated tunneling protocols like  
> IPsec, l2tp or pptp would easily defeat that.

IPsec is not necessarily authenticated.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Aug 2008 17:12:00 -0700

> security policy does not require it.

Understood.  Thanks for clarifying!

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Aug 2008 17:12:00 -0700

> alternatives you mentioned.

If the scope includes IPv6-over-IPv4 tunnels, then there are two 
network topologies:

  1.  CPE gets a single IPv4 address and is an IPv4 NAPT, or
  2.  the residential user gets one IPv4 address for each 
      device in their home that wants to do a IPv6-over-IPv4 
      tunnel.

If (1), I don't see how unsolicited incoming packets can be
directed to the correct host behind the IPv4 NAPT.

If (2), we are outside the realm of simple residential networks -- they only
have one IPv4 address.  We can't plan for more to become common as we approach
IPv4 exhaustion.

Is there another network topology that I am missing?

-d

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Aug 2008 17:54:07 -0700

> Is there another network topology that I am missing?

Ah.   I see the confusion.  In the scope of the whole draft, we are  
talking about CPE that can include dual-stack transition mechanisms.   
In the specific scope of R23, the words "upper layer protocol" are  
intended to imply only IPv6 as the outer layer (which may itself be  
tunneled in an IPv4 transition mechanism, but the filtering  
recommendations in this draft are intended for use in applying filters  
inside the tunnel, not to the outside).

We are not trying to make recommendations about IPv4 simple security  
in this draft.  This could be made more clear.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Aug 2008 18:19:51 -0700

> From: james woodyatt [mailto:[email-masked]] 
> Sent: Wednesday, August 27, 2008 5:54 PM
> To: IPv6 Operations
> Cc: Dan Wing
> Subject: Re: But are we talking IPv6 only? That's how I read 
> the draft. (Re: Some suggestions for 

I was not expecting the draft to discuss IPv4 simple security.

My confusion -- which persists even after reading your email -- is
what this home network (with a dual-stack CPE) looks like:  which 
device(s) terminate IPv6-over-IPv4 tunnels (the CPE itself?  Or a 
host behind the CPE?), which devices get IPv4 addresses (only the 
CPE itself, or also devices behind the CPE?), and so on.

Network diagrams would go a long ways towards my understanding.
If you could whiteboard such a network diagram and send me a JPG
of the whiteboard, I would be happy to build some ASCII art.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 28 Aug 2008 09:48:25 +0200

On Thu, 28 Aug 2008 07:12:00 +0930, Mark Smith

> work):

This is silly. If the user wants to bypass the CPE, (s)he can do it anyway.

The point of a CPE is to provide security that the user _wants_ to have,

not force security upon the user.

We are talking about simple CPEs - not corporate firewalls!

Blocking automatic tunneling (6to4 and/or Teredo) might make sense, but

blocking manually configured tunnel does not - regardless of

authentication.

-- 

Rémi Denis-Courmont

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Aug 2008 08:16:09 -0700

>CPE itself, or also devices behind the CPE?), and so on.

In the case of unsolicited incoming IPv6-in-IPv4 packets,
if the CPE is a 6to4 or ISATAP router, the CPE terminates
the tunnel. (If the site behind the CPE uses ISATAP, the
packets are then admitted into a *different* tunnel that
spans the site behind the CPE.)

If the CPE is *not* configured as either a 6to4 or ISATAP
router, a Teredo tunnel could still be used to direct
encapsulated packets through an open port in the CPE
and to the final destination within the site. (That is,
if the port is being kept open through keepalives sent
by the final destination.)

I haven't read the draft, but I'm pretty sure this stuff
is well known within the v6ops community; does the draft
fail to mention and/or misrepresent any of the above?

Fred
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Aug 2008 08:27:02 -0700

> spans the site behind the CPE.)

(Just stating the obvious, but I want to point out) this 
requires the CPE itself have a publicly-routable v4 address.

> by the final destination.)

Which requires the host behind the CPE (the one running
Teredo) first start up Teredo.  This changes how 'unsolicited
incoming packets'

> fail to mention and/or misrepresent any of the above?

Yes, I am coming into the middle of a discussion; life is
full of such events.  My apologies.

But the assumed model(s) need to be explained, in the draft, 
so that it is clear how those models apply to dual-stack-lite 
and to IVI/NAT64/NAT-PT -- all of which change the assumptions
(due to lack of publicly-routable v4 address for some of
those solutions).  Or, alternatively, if it is this draft's
intent that its model for v6-in-v4 is only intended to work 
if the CPE has a publicly-routable v4 address.

-d

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Aug 2008 08:42:22 -0700

>From: Dan Wing [mailto:[email-masked]] 
>Sent: Thursday, August 28, 2008 8:27 AM
>To: Templin, Fred L; 'james woodyatt'; 'IPv6 Operations'
>Subject: RE: But are we talking IPv6 only? That's how I read 

True for 6to4, but not true for ISATAP; if the CPE were
assigned a private address on it's provider-side interface
it could still be configured as an ISATAP router.

Fred

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Aug 2008 12:31:32 -0700

> if the CPE has a publicly-routable v4 address.

I'll expand on the relevant models for IPv6 transition mechanisms and  
dual-stack service providers in the next revision of the draft.

The minimum set of models I think we should consider are..

A) CPE is a router connected to a native IPv6 service provider with  
prefix delegation.  Note: this includes dual-stack-lite CPE, as  
currently proposed.

B) CPE is an IPv4/NAT router connected to a service provider where  
IPv6-in-IPv4 tunneling is available with a default route to the public  
default-free zone, e.g. 6to4, tunnel-broker, etc.

Are there *any* other realistic models to consider for residential CPE?

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Aug 2008 13:05:49 -0700

>Sent: Thursday, August 28, 2008 12:32 PM
>To: IPv6 Operations

CPE is an IPv4/NAT router connected to a service provider
where IPv6-in-IPv4 tunneling is available with a default
route to a border gateway for the service provider, e.g.,
ISATAP (with private IPv4 address on the CPE's provider-
facing interface).

Fred

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Aug 2008 13:50:05 -0700

> ISATAP (with private IPv4 address on the CPE's provider-

Please correct me if I'm wrong... that's just B) where the tunnel is  
ISATAP.  Right?

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Aug 2008 14:20:00 -0700

>Sent: Thursday, August 28, 2008 1:50 PM
>To: IPv6 Operations

The distinction being drawn between B) and this (call it C),
I guess) is that C) entails a private IPv4 address on the
CPE provider-facing interace; not a public one.

Fred

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Aug 2008 13:55:03 +0200

>> Are there *any* other realistic models to consider for residential CPE?

Not that I see, understanding that 6rd (deployed by Free of the Iliad 
Group, and described in draft-despres-6rd-00) is in the list of B.

> ISATAP (with private IPv4 address on the CPE's provider-

- ISATAP is a tool that assigns full /128 addresses to IPv6 hosts of 
IPv4-only sites.
- If my understanding of the subject is right, it is therefore not a 
tool to assign an IPv6 prefix to a router CPE behind which several hosts 
have teir individual IPv6 addresses. (A prefix shorter than /128 would 
be necesssary, typically /48 to /64).

Regards,

RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Aug 2008 08:03:37 -0700

>From: Rémi Després [mailto:[email-masked]] 
>Sent: Friday, August 29, 2008 4:55 AM
>To: Templin, Fred L
>Cc: james woodyatt; IPv6 Operations
>the draft. (Re:Some suggestions for 

Sorry, but that is too limited a view. ISATAP routers can
indeed be assigned prefixes via DHCPv6 IPv6 prefix delegation
(or manual config) and can function as IPv6 routers for
more-specific prefixes than just ::/0.

In other words, there are "traditional" ISATAP routers that
service default routes for forwarding to end systems outside
of the site and ISATAP routers that service more-specific
routes for forwarding to end systems within the site; even
if the end systems are deeply nested in "sites-within-sites".

Fred

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Aug 2008 17:53:36 +0200

> if the end systems are deeply nested in "sites-within-sites".

Quite interesting.

Is there a document where "non traditional" ISATAP you are refering to
is described?

It should be related to what I am currently working on, namely a generic
architecture for global address tunneling.
- Its scope is IPv4 or IPv6 global addresses, via IPv6 or IPv4 realms in 
which addressing may be global or local.
- It will include 6to4, "traditional" ISATAP, 6rd,  and several new
useful configurations.

The plan is to have a draft for IETF 73.

Rémi

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 29 Aug 2008 09:37:57 -0700

>Sent: Friday, August 29, 2008 8:54 AM
>To: Templin, Fred L
>the draft. (Re:Somesuggestions for 

"Traditional vs. non-traditional" is perhaps not such a great
terminology; better might be "explicitly-stated vs. implicitly-
permitted". But yes, there is a document that expands on what
is implicitly permitted by RFC5214.  

>- It will include 6to4, "traditional" ISATAP, 6rd,  and several new

ISATAP permits tying together disjoint private IPv4
addressing realms at the IPv6 level, where each disjoint
addressing realm can be thought of as a separate site. It
also allows for recursively-nested disjoint private IPv4
addressing realms tied together in an IPv6 prefix delegation
hierarchy.

So, each site has a disjoint IPv4 routing realm and IPv6
routing is used as an overlay that ties the sites together
when IPv6-in-IPv4 encapsulation via ISATAP tunneling is used.
An outward appearance of this from an IPv4 perspective may
be as recursively-nested NATs-within-NATs, so access to
global IPv4 services for nodes that are within deeply-nested
sites may be through multiple levels of NATs. If you find
that distasteful, you can always use something like dual
stack lite and have IPv4-in-IPv6-in-IPv4 - it may seem odd,
but I think you will find it works...

Fred

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Aug 2008 16:45:54 -0700

> >>> Are there *any* other realistic models to consider for 
> residential  
> >>> CPE?
> >>
> >Please correct me if I'm wrong... that's just B) where the 
> >tunnel is ISATAP.  Right?
> 

Both SNAT and Dual-Stack Lite also give private IPv4 addresses
to the CPE.  Figure 1 of draft-droms-softwires-snat-01.txt shows 
the CPE being given a 10.0.0.1 address (RFC1918).  
Sections 4.5 and 4.6 of draft-durand-dual-stack-lite-00.txt 
discuss a Carrier Grade NAT; I expect the IPv4 addresses between
the IPv4 (half of the) CPE and the CGN would be private 
addresses.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Aug 2008 16:50:09 -0700

> I'll expand on the relevant models for IPv6 transition mechanisms 
> and dual-stack service providers in the next revision of the draft.
>
> residential CPE?

The other IPv6 transition mechanisms (IVI, NAT6, NAT64, and even
NAT-PT) all look and feel like your (A), from the perspective of 
the CPE.  Might want to point that out.

-d