Subject: [v6ops] Hmm. Interesting article...

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 1 Feb 2016 21:16:26 +0000

http://arstechnica.com/security/2016/02/using-ipv6-with-linux-youve-likely-been-visited-by-shodan-and-other-scanners/

"Hein said he supports using IPv6 addresses once per connection and limiting the lifespan of an IPv6 address to a single connection. Once the connection is closed, the IPv6 address would be deallocated."

Thought for today. Wouldn't it be better to divide the set of addresses in use by a host into two - those that others may use to connect to it (and are probably advertised in DNS) and those that it uses to connect to other hosts? In a scan of this kind, if the harvested address didn't respond to an incoming connection, the scan would yield little or no value - even with a port scan five seconds later.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 01 Feb 2016 21:38:50 +0000

On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) <[email-masked]> wrote:

> "Hein said he supports using IPv6 addresses once per connection and
> limiting the lifespan of an IPv6 address to a single connection. Once the
> connection is closed, the IPv6 address would be deallocated."
>
Thought for today. Wouldn't it be better to divide the set of addresses in
> use by a host into two - those that others may use to connect to it (and
> are probably advertised in DNS) and those that it uses to connect to other
> hosts? In a scan of this kind, if the harvested address didn't respond to
> an incoming connection, the scan would yield little or no value - even with
> a port scan five seconds later.
>

Something similar (one address per connection) was suggested during some of
the privacy addressing discussions a number of years ago (and it made me
sad). Modern machines make a *large* number of connections / sessions, and
this would require doing the neighbor discovery dance for every connection,
and the router tracking large amounts of state (a slot per connection, not
just per machine).

The bit that I still don't understand  --- in an IPv4 world, you *expect*
every machine with an IP address to be scanned, almost constantly. Why
should things be different in v6 -- is the "plan" really that machines are
secure because no-one can guess their IP (security though obscurity)?

 W

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 1 Feb 2016 21:45:41 +0000

> On Feb 1, 2016, at 1:38 PM, Warren Kumari <[email-masked]> wrote:
> 
> Something similar (one address per connection) was suggested during some of the privacy addressing discussions a number of years ago (and it made me sad). Modern machines make a *large* number of connections / sessions, and this would require doing the neighbor discovery dance for every connection, and the router tracking large amounts of state (a slot per connection, not just per machine).

Well, yes, but the reason given for "and then throw the address away" is to prevent it from being used if it is harvested. I submit that we can achieve that more simply - by not accepting incoming connections to addresses we use for outbound connections. If we make the address go away, we will still see packets to it, we will just not respond to them. If we make temporary addresses be used only for outbound connections, we do the same - but without the level of churn.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 1 Feb 2016 14:03:18 -0800

On 2/1/16 1:38 PM, Warren Kumari wrote:
> 
> 
> On Mon, Feb 1, 2016 at 4:16 PM Fred Baker (fred) <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     limiting the lifespan of an IPv6 address to a single connection.
>     Once the connection is closed, the IPv6 address would be deallocated." 
> 
>     Thought for today. Wouldn't it be better to divide the set of
>     addresses in use by a host into two - those that others may use to
>     connect to it (and are probably advertised in DNS) and those that it
>     uses to connect to other hosts? In a scan of this kind, if the
>     harvested address didn't respond to an incoming connection, the scan
>     would yield little or no value - even with a port scan five seconds
>     later.
> 
> 
> Something similar (one address per connection) was suggested during some
> of the privacy addressing discussions a number of years ago (and it made
> me sad). Modern machines make a *large* number of connections /
> sessions, and this would require doing the neighbor discovery dance for
> every connection, and the router tracking large amounts of state (a slot
> per connection, not just per machine).

if on the other hand you delegate a prefix to the machine, you can
optimize for that case by using it's link-local as the nexthop for the
entire prefix, it can use as many ip's as it want's and you never do any
ND for any of them.

> 
> The bit that I still don't understand  --- in an IPv4 world, you
> *expect* every machine with an IP address to be scanned, almost
> constantly. Why should things be different in v6 -- is the "plan" really
> that machines are secure because no-one can guess their IP (security
> though obscurity)? 
> 
>  W
> 
>     [email-masked] <mailto:[email-masked]>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 1 Feb 2016 22:09:45 +0000

> On Feb 1, 2016, at 2:03 PM, joel jaeggli <[email-masked]> wrote:
> 

However, that's not the issue the article is point out. It's pointing out that if a harvested address used for an outbound connection can also be used for an inbound connection, there is a security vulnerability.

Warren suggested making the address go away when it is no longer in use.

I'm suggesting making the firewall in the host block incoming connections to temporary addresses, which has the same effect without the churn.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 1 Feb 2016 22:10:49 +0000

> The bit that I still don't understand  --- in an IPv4 world, you *expect* every machine with an IP address to be scanned, almost constantly. Why should things be different in v6 -- is the "plan" really that machines are secure because no-one can guess their IP (security though obscurity)?

Yes, this is one of the selling features of IPv6.   It's not security through obscurity any more than using a 2048-bit key instead of a 1024-bit key is security through obscurity: its a mechanism for increasing the search space beyond the capability of the attacker to explore it economically.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 1 Feb 2016 14:25:03 -0800

It’s rather amusing watching you guys talk past each other without realizing that you’re basically saying mostly the same thing with slightly different approaches that could actually work together.

Approach 1: Address goes poof as soon as it is finished with outbound connection.
	Pros: Easily implemented, doesn’t significantly change existing codebases.
	Cons: Absurd excessive neighbor discovery traffic
	Workaround: Make every host a router. Assign all the temporary prefixes from a subnet assigned to the loopback interface and route
			via LL address of ethernet interface(s).
		Pros: Easily implemented, solves problem
		Cons: potentially excessive prefix consumption, possibly very excessive, potential unexpected consequences of host being made
			into a router, potentially without administrator realizing that has occurred. (violates principle of least surprise)

Approach 2: Address can stay (or not), but temporary addresses are flagged for outbound only and host-firewall
	is automatically configured to reject inbound session initiation packets to that address.

	Pros: Eliminates ND issues for the most part, efficient, doesn’t require every host to become a router.
	Cons: Significant code changes to most hosts to implement this functionality, couples a number of previously uncoupled systems,
		high probability of user confusion (violates principle of least surprise).

The thing that strikes me most about this is that a host which has an adequate stateful inspection firewall in front of it realy has no more issue
from it’s IPv6 address being harvested than it does from its IPv4 address being harvested, so I’m not seeing how this is news or how it really
represents any sort of inherent vulnerability.

Perhaps someone can enlighten me as to how this is some new security issue we should be concerned about, but for now, it appears to me as if it is much ado about nothing.

Owen

> On Feb 1, 2016, at 14:09 , Fred Baker (fred) <[email-masked]> wrote:
> 
>>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 1 Feb 2016 15:04:46 -0800

>>> addresses in use by a host into two - those that others may use 
>>> to connect to it (and are probably advertised in DNS) and those 
>>> that it uses to connect to other hosts? In a scan of this kind, 
>>> if the harvested address didn't respond to an incoming 
>>> connection, the scan would yield little or no value - even with
>>> Something similar (one address per connection) was suggested 
>>> during some of the privacy addressing discussions a number of 
>>> years ago (and it made me sad). Modern machines make a *large* 
>>> number of connections / sessions, and this would require doing 
>>> the neighbor discovery dance for every connection, and the
>>> router tracking large amounts of state (a slot per connection,
>>> not just per machine).
>> 
>>  optimize for that case by using it's link-local as the nexthop
>> for the entire prefix, it can use as many ip's as it want's and
>> you never do any ND for any of them.
> 
> However, that's not the issue the article is point out. It's
> pointing out that if a harvested address used for an outbound
> connection can also be used for an inbound connection, there is a
> security vulnerability.
> 
> I'm suggesting making the firewall in the host block incoming 
> connections to temporary addresses, which has the same effect
> without the churn.

it is perhaps reasonable to expect for modern hosts (and devices like
CPE) to implement stateful inspection firewalls. Some devices have
listening services. it would seem natural for listening services to be
bound to some IPs and not others (though all of them is probably also
relatively normal). if you're going to use addresses ephemerally it
would see reasonable to not accept incoming connections on those IPs.

If an ND entry is required for every IP you use that cost gets borne by
any router requiring an ND entry until the cache expires irrespective of
your intent to answer or not.

>>>  constantly. Why should things be different in v6 -- is the
>>> "plan" really that machines are secure because no-one can guess
>>> their IP (security though obscurity)?
>>> W
>>> 
>>> _______________________________________________ v6ops mailing 
>>> list [email-masked] <mailto:[email-masked]> 
>>> _______________________________________________ v6ops mailing 
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> 
>

---

From: Ca By <[email-masked]>
Date: Mon, 1 Feb 2016 16:22:04 -0800

On Monday, February 1, 2016, Fred Baker (fred) <[email-masked]> wrote:

>
> > On Feb 1, 2016, at 2:03 PM, joel jaeggli <[email-masked]
> <javascript:;>> wrote:
> >
> <javascript:;>
> >> <mailto:[email-masked] <javascript:;>>> wrote:
> >>
> >>
> However, that's not the issue the article is point out. It's pointing out
> that if a harvested address used for an outbound connection can also be
> used for an inbound connection, there is a security vulnerability.
>
> I'm suggesting making the firewall in the host block incoming connections
> to temporary addresses, which has the same effect without the churn.
>
>
Why is this firewall only for temp addresses ?

If the host is not listening on that port, why do you need a fw?

At the end of the day, these are app issues (shodan tries default password
) and network should stay out of it.

> >>    [email-masked] <javascript:;> <mailto:[email-masked] <javascript:;>>
> >> [email-masked] <javascript:;>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 04:56:25 -0300

On 02/01/2016 07:25 PM, Owen DeLong wrote:
[...]
> 
> The thing that strikes me most about this is that a host which has an
> adequate stateful inspection firewall in front of it realy has no more issue
> from it’s IPv6 address being harvested than it does from its IPv4
> address being harvested, so I’m not seeing how this is news or how it really
> Perhaps someone can enlighten me as to how this is some new security
> issue we should be concerned about, but for now, it appears to me as if
> it is much ado about nothing.

Maybe in that in IPv4 you typically have a NAT in front of your node,
where in IPv6 you don't necessarily have a fw?

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 05:00:51 -0300

On 02/01/2016 09:22 PM, Ca By wrote:
[....]
> If the host is not listening on that port, why do you need a fw?

Among other reasons, because of this sort of thing:
<https://threatpost.com/freebsd-patches-kernel-panic-vulnerability/116001/>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 04:46:57 -0300

On 02/01/2016 06:16 PM, Fred Baker (fred) wrote:
> limiting the lifespan of an IPv6 address to a single connection. Once
> the connection is closed, the IPv6 address would be deallocated."
> 

Sounds like temporary addresses (RFC4941) vs stable addresses (RFC7217
or traditional slaac), with the only difference in that a listening
socket shouldn't be bound to wildcard, or wildcard should not imply temp
addr...

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 04:49:46 -0300

> that machines are secure because no-one can guess their IP (security

Addresses can actually be guessed. See
<https://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-08>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 04:53:54 -0300

> I'm suggesting making the firewall in the host block incoming connections to temporary addresses, which has the same effect without the churn.

I agee wth you on the desired outcome, but wonder if this should rather
be a policy of the host itself (i.e., temp addrs simply not used for
incomming connections.. e.g., wildcard not implying it, or a
setsockopt() to override that) rather than a policy enforced at the
firewall...

---

From: Mark Smith <[email-masked]>
Date: Tue, 2 Feb 2016 20:25:54 +1100

On 2 Feb 2016 8:16 am, "Fred Baker (fred)" <[email-masked]> wrote:

I think the unstated but implied concern in this article is that the hosts
whose addresses are recorded are completely open and vulnerable to port
scans once their address has been discovered. In other words, IPv6 hosts do
not have host based firewalls of any type at all - they've been totally
relying on obscurity on a large address for all protection.

I think that is a false concern. I think the absence of NAT "firewalls" and
such easy host mobility will have created a strong incentive for host OS
developers to make their hosts Internet "proof" by default (for example
Windows has had a host firewall enabled by default since Windows XP service
pack 2, released more than a decade ago).

There seems to have developed such an absolute faith in network firewalls
always being present and working 100% successfully that many people haven't
noticed that hosts have developed those capabilities too, and those
capabilities are what have been protecting their hosts when they're moved
and attached to far less trustworthy networks like cafe, hotel, shopping
centre and conference networks.

The article doesn't mention anything, and I haven't had a look yet, but
what has Shodan actually discovered on the IPv6 hosts it was able to scan?
Is there really a problem, and how severe is it?

> Thought for today. Wouldn't it be better to divide the set of addresses
in use by a host into two - those that others may use to connect to it (and

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Tue, 02 Feb 2016 10:26:01 +0100

> Thought for today. Wouldn't it be better to divide the set of addresses in use by a host into two - those that others may use to connect to it (and are probably advertised in DNS) and those that it…
There was a message on the NTP pool list very recently 
(http://www.pool.ntp.org/en/) saying that Shodan was harvesting 
addresses from communications with public NTP servers.

The NTP servers were being inserted into the public pool (as correctly 
functioning NTP servers) and the Shodan scans were being initiated from 
other apparently unrelated addresses. So it looks like they were simply 
passively monitoring the NTP communications to harvest target addresses 
for a scanning mill. Obviously a lot of machines use the NTP pool (at 
boot time).

Rotating source addresses on the NTP client could have potential impact 
on the NTP server, as the server would see "more" clients, and generally 
the server maintains some state for these. [denial of service attack on 
peer stats anyone?]

Also not so easy to statefully firewall UDP communications, unless you 
specifically bind the NTP client to a particular address used 
exclusively for NTP, and have the client application ignore all 
unexpected inbound messages.

So in short, this looks like an application level issue to me.
Applications need to only bind to the correct addresses.
And clients need to correctly filter inbound (reply) messages.

Another approach might be to build a distributed defence.

If you could set up honeypot NTP clients that only sent outbound packets 
to the pool servers using specific 'nonce generated' client-addresses, 
and then checked if these specific addresses were being scanned some 
time later, you could identify which NTP servers were being used for 
address harvesting, and also which addresses were being used as 
scanners. Then a public DNSBL could potentially be used for configuring 
firewalls in a similar way to how spammers are blocked for SMTP, or the 
NTP servers used for harvesting thrown out of the pool.

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 06:50:47 -0300

> And clients need to correctly filter inbound (reply) messages.

This is non-trivial. e.g., say you hav configured multiple static
addresses (different prefixes)... it's not trivial to find all of them,
left alone actually bind() only such subset.

that's why at some point we were planning an update to an existing API
RFC...

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Tue, 02 Feb 2016 12:15:32 +0100

> Fernando Gont <mailto:[email-masked]>
> 2 Feb 2016 10:50
>
Well it may not be trivial, but I do think it needs attention.

As a starting point, bind to wildcard should not bind to temporary 
addresses, and connect should not send on static addresses. That's 
really not much more than the existing convention of binding to port 
<1024 requiring root.

Then after that, IMVHO you'll probably be looking more at issues around 
mapping machine name + service name -> server address + server port e.g. 
using DNS SD, instead of separate DNS + /etc/services; rather than 
extensively changing the existing socket API. Then the OS could perform 
the appropriate binding(s), as well as registering the appropriate 
name(s), without too much intervention by the application server code.

These binding issues are going to pop up on modern highly mobile devices 
anyway, regardless of the scanning threat. e.g. I don't want my mobile 
phone offering a bulk photo transfer service on the 4g port, but I'd 
quite like the voice to failover between 4g and wifi, and the name 
service really needs updated as I move into wifi radio range of my 
friend's house.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 08:36:19 -0300

> Well it may not be trivial, but I do think it needs attention.

Agreed.

> really not much more than the existing convention of binding to port

Agreed

> extensively changing the existing socket API. 

I'd that, besides some possible tweaking, the issue is that apps should
be using a higher-level api.

Thanks!

Cheers,

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 2 Feb 2016 11:54:24 +0000

> On Feb 1, 2016, at 11:53 PM, Fernando Gont <[email-masked]> wrote:
> 

We're saying the same thing.

The host firewall is in the host. I don't know what else to call it; the thing that looks at packets coming in and decides whether to present them to an application.

A comment was made that if the port is closed (there is no application currently using the port) the host won't respond. Actually not true; per spec, it responds "port unreachable". And if the port happens to be open, it will in fact respond.

However, if we were to somehow say that remote hosts are not permitted to open a session *to* a temporary address, there's no question.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 2 Feb 2016 11:56:39 +0000

> On Feb 2, 2016, at 1:25 AM, Mark Smith <[email-masked]> wrote:
> 
> The article doesn't mention anything, and I haven't had a look yet, but what has Shodan actually discovered on the IPv6 hosts it was able to scan? Is there really a problem, and how severe is it?

As you say, that's not clear. The port scan, however, covers 115 ports (unspecified). One might guess that there has been some level of success, or they wouldn't be doing it.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 09:14:11 -0300

On 02/02/2016 08:54 AM, Fred Baker (fred) wrote:
>> I agee wth you on the desired outcome, but wonder if this should
>> rather be a policy of the host itself (i.e., temp addrs simply not
>> used for incomming connections.. e.g., wildcard not implying it, or
>> a setsockopt() to override that) rather than a policy enforced at
>> the firewall...
> 
> The host firewall is in the host. I don't know what else to call it;
> the thing that looks at packets coming in and decides whether to
> present them to an application.

I'm saying that, besides this functionality being implemented in a
host-based firewall, the API should provide the means for enabling the
"only listen on stable address, only send connection requests from the
temp addr".... or maybe even default to this, and allow to override such
default with "listen on all interfaces, connect from whataver
saddr-selection we should be connecting from".

> A comment was made that if the port is closed (there is no
> application currently using the port) the host won't respond.
> Actually not true; per spec, it responds "port unreachable". And if
> the port happens to be open, it will in fact respond.

1) You're right: that's not true.

2) Even if that was the case, the firewall would reduce the attack
surface. -- e.g., in the advisory I posted, the firewall would prevent
the breach, while the "closed port" wouldn't.

> However, if we were to somehow say that remote hosts are not
> permitted to open a session *to* a temporary address, there's no
> question.

Even than, right now that is not really the case. IN that respect, temp
addrs are just an addr, as the stable one.

(i.e., that what actually happens... not that it *should* happen)...

---

From: Owen DeLong <[email-masked]>
Date: Tue, 2 Feb 2016 05:20:16 -0800

> On Feb 1, 2016, at 23:56, Fernando Gont <[email-masked]> wrote:
> 

If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem.

Owen

---

From: Enno Rey <[email-masked]>
Date: Tue, 2 Feb 2016 14:31:21 +0100

Owen,

> If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem.

that's a very interesting statement, taking the end-to-end principle into account, which IPv6 strives to realize/bring back.
Further I didn't have the impression so far that the Internet of Things necessarily included filtering. My parents currently furnishing their smart home weren't either.

thanks

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 11:33:15 -0300

> If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem.

There's a reason for deploying network-based firewalls:
<https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-01>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 11:35:38 -0300

> If you're running a host without any sort of filter, that's really not a problem we should be solving at the network level. That's more of an educational problem.

Besides, in th IoT world, the "host" may be a network-connected lamp
with some crappy-and-impopssible-to-upgrade-or-even-adminisiter firmware...

... i.e., you will need the network based firewall. In fact, in many
scenarios that's easier to administer, etc.

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 2 Feb 2016 15:24:11 +0000

On 2/2/16, 9:33 AM, "v6ops on behalf of Fernando Gont"
<[email-masked] on behalf of [email-masked]> wrote:

>> If you're running a host without any sort of filter, that's really not
>>a problem we should be solving at the network level. That's more of an
>>educational problem.
>

There is an unaddressed tension here.
I think one view is that IPv6 should be deployed without firewalls so all
hosts are reachable from arbitrary other hosts on the Internet.
I think the other view is that all/most/many hosts should be protected by
a stateful firewall.

I don¹t know that we can resolve this tension in v6ops, but I want to make
it explicit.

Lee

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Feb 2016 12:34:22 -0300

> hosts are reachable from arbitrary other hosts on the Internet.

The folk busted by the recent ICMPv6-based freebsd exploit has a good
example regarding why you don't want to be reachable by everyone when
you don't really need that.

"Need to know basis", "principle of least privilege"... i.e., you are
not allowed to do and something that you're not really required to do...

> I don¹t know that we can resolve this tension in v6ops, but I want to make

Folks aiming at end to end connectivity have traditionally assumed that
the "host" is some sort of computer (laptop, tablet, etc.) whereas
"host" really becomes any crappy device that becomes IPv6-enabled...
possibly with sloppy code, unmanaged, and possibly not even possible to
upgrade. -- No.. you don't want that stuff eachable from anyone in the
Internet.

---

From: Ca By <[email-masked]>
Date: Tue, 2 Feb 2016 08:09:08 -0800

> you don't really need that.
Except for everyone with a FreeBSD based network based firewalls.

In my experience, firewalls are a single point of failure that are
generally more prone to attacks (state exhaustion, ALG mishandling bugs and
associated platform crashes, ...) than anything else.  A firewall is a
host, so it has all those same host issues you speak of.

The biggest sources of network based DDoS today that is crushing the
internet daily ....is generally labeled a "home firewall" ...these
firewalls seem to expose UDP 1900, Chargen, NTP, and others.... The label
says firewall.

So, excuse me if i don't think firewalls do what you think they do in the
real world.  In my experience, they are the vector of the worst attacks and
concentrate the risk of a site going off-line into a single box that is
more vulnerable (since it is running exotic ALGs, UPNP, PCP ...)  than any
other box

CB

---

From: Ca By <[email-masked]>
Date: Tue, 2 Feb 2016 08:17:32 -0800

> more vulnerable (since it is running exotic ALGs, UPNP, PCP ...)  than any

Oh, and they also create really nice backdoors into something you call the
"trusted area"

http://arstechnica.com/security/2016/01/et-tu-fortinet-hard-coded-password-raises-new-backdoor-eavesdropping-fears/

Fortinet, Juniper, Nearly every home router....

So...tell me... where do you come up with this idea that firewalls help?

There is a lot of evidence they make things worse.  Firewalls have the
following *fundamental* architectural failings

0. Long history of being seriously owned, including recent backdoor issues.

1. They make users feel falsely secure so they make bad assumption about
the "secure network"

2. Commonly hit with state exhaustion attacks

3.  Architecturally they are generally deployed as a single door to the
network, so they are a single point of failure....even more hilarious is
when a vendor sells an high-availability pair and the state bug is reflect
from the HOT node to the standby node and they both crash

4.  They do advanced stateful packet fiddling, which is highly error prone
(UPNP, PCP, other ALGs)

I have been hit with evey one of the above.

CB

---

From: Owen DeLong <[email-masked]>
Date: Tue, 2 Feb 2016 09:44:39 -0800

> On Feb 2, 2016, at 06:33 , Fernando Gont <[email-masked]> wrote:
> 

A network-based firewall is one form of filter. I’m not sure why you think my statement was antithetical to that.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 2 Feb 2016 09:44:02 -0800

> On Feb 2, 2016, at 05:31 , Enno Rey <[email-masked]> wrote:
> 
> Owen,
> 

Why? There’s nothing about filters that interferes with the end-to-end principle.

A Stateful inspection firewall that doesn’t mangle the packet header is perfectly acceptable in an end-to-end world. Whether it’s a network-level firewall, a host-level firewall, both, etc.

> Further I didn't have the impression so far that the Internet of Things necessarily included filtering. My parents currently furnishing their smart home weren't either.

Again, you are making a lot of assumptions about the meaning of my statement that are not contained in my actual statement. I hope my response above clarifies this and allows you a cleaner perspective.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 2 Feb 2016 09:46:03 -0800

> On Feb 2, 2016, at 06:35 , Fernando Gont <[email-masked]> wrote:
> 
> with some crappy-and-impopssible-to-upgrade-or-even-adminisiter firmware…

If your lamp doesn’t have a firewall with a packet filter or stateful inspection in front of it, then you deserve your house blinking radically at all hours of the day or night…

However, I said “without any sort of filter”. Not “without a host-based filter”, so I’m still unclear on how this is a relevant response to what I said.

Owen

---

From: Tim Chown <[email-masked]>
Date: Tue, 2 Feb 2016 18:31:45 +0000

> On 2 Feb 2016, at 15:24, Howard, Lee <[email-masked]> wrote:
> 
> 

Well, we’ve seen a few firewall models put forward in v6ops. RFC 6092 seems
to have been generally well received. It may well be the only one that made it
to RFC status? e.g. draft-ietf-v6ops-balanced-ipv6-security-01 stopped at that 
version. 

Tim

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 2 Feb 2016 18:45:20 +0000

> On Feb 2, 2016, at 10:31 AM, Tim Chown <[email-masked]> wrote:
> 

That is explicitly why Fernando and I are trying to have a firewall discussion in opsawg (draft-gont-opsawg-firewalls-analysis). RFC 6092 is certainly a common firewall model (modeling a NAT's behavior), but I would say that the consensus supporting it was "rough". The other firewall models proposed (draft-ietf-v6ops-balanced-ipv6-security, draft-vyncke-advanced-ipv6-security) basically pushed towards firewall-as-a-service, and as such gutted the filter function.

I'll refer us to that discussion if we want to go general on firewall functionality.

My question here was essentially about finding a simple rule *on*the*host* that might obviate a lot of attacks and probing. The conclusion that I draw is that I can do anything I want as long as I don't change anything, and yes, my suggestion is a change. I actually do think there may be value in it, however.

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Feb 2016 06:36:51 +1100

>
> that's a very interesting statement, taking the end-to-end principle into
account, which IPv6 strives to realize/bring back.

The end-to-end principle effectively asserts that hosts should be
performing their own filtering/security.

e2e is saying that hosts shouldn't rely on the network to perform functions
the hosts themselves have to most and greatest interest in being performed,
which includes protecting against malicious traffic that arrives over the
network.

The end to end reachability that IPv6 aims to restore is a network
property. It doesn't mean that a host must accept and trust all packets
that arrive over the network.

It doesn't preclude security functions being performed in the network, but
it means they shouldn't be a mandatory part of the architecture, shouldn't
be assumed to be there and assumed to be consistently equivalent and
"perfect" for the individual hosts' and their applications requirements.

Hosts have the greatest interest in their own security so they need to make
the greatest effort to ensure it is done and done well.

> Further I didn't have the impression so far that the Internet of Things
necessarily included filtering. My parents currently furnishing their smart
home weren't either.

It should, similar to how nobody would build a house without putting locks
on the door.

Your parents should be able to trust device vendors to buy "Internet proof"
devices if the device has even the slightest possibility of being  attached
to the Internet.

The alternative is to have a big sticker on the box that says "must be
behind a network firewall", which might get a vendor out of some of their
device robustness responsibility, but isn't really looking after their
customer well.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Feb 2016 06:47:48 +1100

Which I think is evidence that host level security is now actually more
effective in many cases than CPE/firewall security. The attackers are going
after the weakest link.

Regards,
Mark.

---

From: Enno Rey <[email-masked]>
Date: Tue, 2 Feb 2016 22:13:31 +0100

Hi,

> On 02/02/2016 09:44 AM, Owen DeLong wrote:
> >>> If you're running a host without any sort of filter, that's
> >>> really not a problem we should be solving at the network level.
> >>> That's more of an educational problem.
> >> 
> >> that's a very interesting statement, taking the end-to-end
> >> principle into account, which IPv6 strives to realize/bring back.
> > 
> > Why? There???s nothing about filters that interferes with the
> > end-to-end principle.
> > 
> > A Stateful inspection firewall that doesn???t mangle the packet header
> > is perfectly acceptable in an end-to-end world. Whether it???s a
> > network-level firewall, a host-level firewall, both, etc.

a network-level "stateful inspection" firewall keeps track of, well, state. doing so "in the network" is a - from my understanding - fundamental violation of the e2e principle, not least as it impedes "survivability in the face of failure".

best

Enno

-- 
Enno Rey

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Feb 2016 08:35:55 +1100

On 3 Feb 2016 8:13 AM, "Enno Rey" <[email-masked]> wrote:
> a network-level "stateful inspection" firewall keeps track of, well,
state. doing so "in the network" is a - from my understanding - fundamental
violation of the e2e principle, not least as it impedes "survivability in
the face of failure".

Right, and forwarding plane state also creates opportunities for attackers
to exhaust that state.

So if network located packet validation is considered necessary, then I
think stateless packet filtering in the network and stateful host
firewalling is the more robust model that also satisfies the e2e principle.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Feb 2016 13:48:05 -0800

On 2/2/2016 1:35 PM, Mark Smith wrote:
>> > > Why? There's nothing about filters that interferes with the
>> > > end-to-end principle.

I'm not sure how far back that quote goes, but it's correct only if the
filters inspect no further than the network (IP) header.

The transport header is meaningful only at the endpoints. They can
change those headers at will - i.e., change port numbers or transport
protocol numbers, etc., subject to agreement of the endpoints.

Anything except the endpoints that interprets those headers is a
violation of E2E. It may be desired, useful, or even common, but it's
not E2E-compliant.

Joe

---

From: Owen DeLong <[email-masked]>
Date: Tue, 2 Feb 2016 14:14:26 -0800

> On Feb 2, 2016, at 13:48 , Joe Touch <[email-masked]> wrote:
> 
> 
> 

We can agree to disagree.

It is my NSHO that if you do not alter the packets you allow to pass,
your inspection of the higher layer headers in making a security decision
is not a violation of e2e.

Owen

---

From: Joe Touch <[email-masked]>
Date: Tue, 2 Feb 2016 14:30:57 -0800

> is not a violation of e2e.

If the net behaves differently in any way based on anything above L3,
then that is the violation. That may involve blocking, etc.

Further, IMO, any interpretation of info above L3 is a risk - the
endpoints are allowed to negotiate those layers, headers, and parameters
as they see fit. There is no strict rule that port 53 is DNS - when you
block based on port at an intermediate device, that device is *assuming*
understanding of that port. That can be (and often is) incorrect.

Joe

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 2 Feb 2016 18:30:51 -0800

> a network-level "stateful inspection" firewall keeps track of, well, state. doing so "in the network" is a - from my understanding - fundamental violation of the e2e principle, not least as it impe…

The network itself does not have infinite bandwidth (and never will), and needs protection from denial of service attacks by sending unsolicited traffic.  Even if the host (IoT light bulb) drops the packet, the network path may well be saturated with those discarded packets.  We have a few small attempts to push that filtering away from the host into the network (one example is PCP's FILTER option in RFC6887), but few people see the need.  I expect as network connectivity becomes more necessary for businesses and homes, and attacks continue to proliferate, the need to filter in the network will remain and will become more controllable by hosts.

-d

---

From: Owen DeLong <[email-masked]>
Date: Tue, 2 Feb 2016 21:15:27 -0800

> On Feb 2, 2016, at 14:30 , Joe Touch <[email-masked]> wrote:
> 
> 
> 

When I decide at the ingress to a collection of machines that I administer
or have responsibility for securing that port 53 is not a port that I want
to allow traffic on, it doesn’t matter whether the guy at the other end is
thinking it is DNS, Foozball tournament stats, or a message direct to the pope,
it’s traffic I’ve decided to administratively deny.

Doing so at the network level at the ingress to my network is perfectly valid
and does not, IMNSHO constitute a layering violation or a violation of e2e.

Mutilating the packet and then passing along what remains would, IMNSHO
violate e2e because what arrives differs from what was sent in a meaningful
way. Having what was sent never arrive at all due to my security policy is
not a violation.

Now, if a transit AS starts making such filtration, I would agree with you.

But a network administrator filtering the ingress to networks exclusively
containing machines for which he/she has responsibility and/or authority
is no such violation.

In this case, the network is not assuming that it understands the semantics
negotiated by the end points, the network is assuming that the guy who
configured the filter understands the policy he intends to implement.

Owen

---

From: Mark Smith <[email-masked]>
Date: Wed, 3 Feb 2016 18:25:25 +1100

>
> The network itself does not have infinite bandwidth (and never will), and
needs protection from denial of service attacks by sending unsolicited
traffic.  Even if the host (IoT light bulb) drops the packet, the network
path may well be saturated with those discarded packets.  We have a few
small attempts to push that filtering away from the host into the network
(one example is PCP's FILTER option in RFC6887), but few people see the
need.  I expect as network connectivity becomes more necessary for
businesses and homes, and attacks continue to proliferate, the need to
filter in the network will remain and will become more controllable by
hosts.

So I don't think it is really necessary, and I think it is actually useful
that the network doesn't try to understand specific host/end protocols to
perform anti-DoS mitigation.

I think DoS mitigation could be more effectively and more generically
achieved by network devices just performing bit pattern matching on
packets, which matches what is basically happening in the TCAMs. An
external tool of some sort would convert protocol fields it understands
into bit pattern specifications before they're pushed into the network
device performing the inspection. That would be stateless, while providing
a lot of upper layer inspection flexibility.

Regards,
Mark.

---

From: Joe Touch <[email-masked]>
Date: Wed, 3 Feb 2016 06:04:25 -0800

On 2/2/2016 9:15 PM, Owen DeLong wrote:
...
> it’s traffic I’ve decided to administratively deny.

The "end" of E2E is often ambiguous.

>From a protocol viewpoint, it is the host to whom the IP address is
assigned, never anything else.

Administratively, if you think it is your right to act on behalf of that
endpoint *AND* that endpoint agrees to delegate that right, then you are
really just semantically redefining "endpoint" to mean "the entire
endsystem under your adminstrative control".

However, that will work ONLY when the E2E protocol *ALSO* is
coordinated. I.e., you can block port 53 all day long and I can continue
to run DNS on another port, or run anything on port 53 inside a tunnel
(e.g., encrypted or just with enough layers that you don't inspect).

I.e., whether this is valid is NOT solely your decision, regardless of
what you *think* your authority is. The endsystem with the given IP
address still has to cooperate with you or your solution will not have
the desired effect.

That delegation can happen anywhere in the net, but it's not so much a
violation of the E2E argument as a redefinition that the endpoint is
spread out.

It doesn't matter whether you are "mutilating" a packet or discarding
it, delaying it, or treating it in any way different from packets you
don't deep inspect. In any case, any differential treatment is a
violation of E2E.

I do appreciate that we violate E2E all the time for a variety of
practical reasons, but the result always has the potential consequence
of unintentionally interfering with valid E2E communication.

...
> configured the filter understands the policy he intends to implement.

It is the person who configures the filter who ASSUMES they can know the
consequence of a L4 or higher filter. It is an ASSUMPTION. No amount of
"understanding" can overcome the fact that L4 and higher semantics are
knowable ONLY at the endpoints.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Wed, 3 Feb 2016 08:37:21 -0800

> is not a violation of e2e.
What about the case where packets are dropped by an intermediate
device because it doesn't understand some legitimate L4 protocol or
isn't able to find the L4 header because it doesn't parse all the ext.
hdrs. This sort of thing is a major culprit of protocol ossification
on the Internet. Because of this it's infeasible for us (end users) to
deploy SCTP, IP option, ext. hdrs. etc. Other than being stuck with
TCP forever, it seem like the only recourse we currently have is
encapsulating "alternative" L4 protocols in UDP, but that leads to
it's own problems.

Tom

---

From: Ca By <[email-masked]>
Date: Wed, 3 Feb 2016 09:18:59 -0800

> encapsulating "alternative" L4 protocols in UDP, but that leads to
Alas, UDP will / is be blocked as well. UDP profiles for rate limiting are
sticky around the heuristic that UDP is less than 5% of traffic during
normal operations, and excess traffic over that heuristic is 100%
correlated with outrage causing UDP ddos (CHARGEN, DNS, NTP, UPNP, ....)

https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 03 Feb 2016 17:25:04 +0000

> encapsulating "alternative" L4 protocols in UDP, but that leads to

This is the main subject of draft-gont-v6ops-ipv6-ehs-packet-drops.

Nick

---

From: Owen DeLong <[email-masked]>
Date: Wed, 3 Feb 2016 11:45:16 -0800

> I think DoS mitigation could be more effectively and more generically achieved by network devices just performing bit pattern matching on packets, which matches what is basically happening in the TCAMs. An external tool of some sort would convert protocol fields it understands into bit pattern specifications before they're pushed into the network device performing the inspection. That would be stateless, while providing a lot of upper layer inspection flexibility.
> 
Most of the real dDOS tools worked around that form of mitigation many years ago. Even if they hadn’t, it is trivial to do so and widespread deployment of your recommendation would be a lot of work to achieve while taking about 10 minutes of coding to defeat.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 3 Feb 2016 11:50:30 -0800

> Alas, UDP will / is be blocked as well. UDP profiles for rate limiting are sticky around the heuristic that UDP is less than 5% of traffic during normal operations, and excess traffic over that heuristic is 100% correlated with outrage causing UDP ddos (CHARGEN, DNS, NTP, UPNP, ….)

I’m going to go out on a limb and say that there are a number of networks where that simply isn’t the case… (Think VOIP service providers, for example).

Owen

---

From: Mark Smith <[email-masked]>
Date: Thu, 4 Feb 2016 08:07:18 +1100

>
> Most of the real dDOS tools worked around that form of mitigation many
years ago. Even if they hadn’t, it is trivial to do so and widespread
deployment of your recommendation would be a lot of work to achieve while
taking about 10 minutes of coding to defeat.

Example please.

Demonstrate how an inflexible packet matching device that hard interprets
packet field layouts and values is going to be more effective than a device
that can match any specified bit pattern in any location in the packet,
including bit patterns that can span multiple traditional packet fields.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 3 Feb 2016 13:43:13 -0800

> On Feb 3, 2016, at 13:07 , Mark Smith <[email-masked]> wrote:
> 
> 
> On 4 Feb 2016 6:46 AM, "Owen DeLong" <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> Demonstrate how an inflexible packet matching device that hard interprets packet field layouts and values is going to be more effective than a device that can match any specified bit pattern in any location in the packet, including bit patterns that can span multiple traditional packet fields.
> 
Most packet matching devices used for dDOS mitigation in the modern world are not inflexible. Hence your claim depends on an invalid assertion.

Owen

---

From: Joe Touch <[email-masked]>
Date: Wed, 3 Feb 2016 15:24:30 -0800

On 2/3/2016 8:37 AM, Tom Herbert wrote:
> hdrs. 

Or IPsec.

Joe

---

From: Owen DeLong <[email-masked]>
Date: Wed, 3 Feb 2016 20:26:39 -0800

> encapsulating "alternative" L4 protocols in UDP, but that leads to

First, being unable to find the L4 header because you can’t parse the ext. headers shouldn’t happen. Extension headers are all designed with standard parameters at the beginning allowing them to be skipped if they are not understood.

If the intermediate system is under a different authority than the end host, I agree this is inappropriate and have said so. Note, different authority here gets murky. For example, the security department of XYZ, Inc. is not for this purpose IMHO a different authority from the rest of XYZ, Inc.

OTOH, if $ISP is blocking packets for their customers that their customers would prefer to see, then $ISP is both a different authority _AND_ quite thoroughly in the wrong.

Most of the protocol ossification I have observed relates to what will pass NAT vs. what won’t.

A little bit results from corporate policies that seem to think forcing everyone to use HTTPs and DNS to encapsulate everything else somehow improves their security posture.

NAT is largely an IPv4 problem. The other is largely an educational problem.

Owen

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 07:53:10 -0300

> A network-based firewall is one form of filter. I’m not sure why you think my statement was antithetical to that.

I took your statement as implying that a host should run its own filters.

Looks like it was a misunderstanding on my side -- my apologies.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 07:56:04 -0300

On 02/02/2016 02:46 PM, Owen DeLong wrote:
>>>>> On 02/01/2016 07:25 PM, Owen DeLong wrote: [...]
>>>>> 
>>>>> The thing that strikes me most about this is that a host
>>>>> which has an adequate stateful inspection firewall in front
>>>>> of it realy has no more issue from it’s IPv6 address being
>>>>> harvested than it does from its IPv4 address being harvested,
>>>>> so I’m not seeing how this is news or how it really 
>>>>> Perhaps someone can enlighten me as to how this is some new
>>>>> security issue we should be concerned about, but for now, it
>>>>> appears to me as if it is much ado about nothing.
>>>> 
>>>> Maybe in that in IPv4 you typically have a NAT in front of your
>>>> node, where in IPv6 you don't necessarily have a fw?
>>>> 
>>> 
>> Besides, in th IoT world, the "host" may be a network-connected
>> lamp with some
>> crappy-and-impopssible-to-upgrade-or-even-adminisiter firmware…
> 
> If your lamp doesn’t have a firewall with a packet filter or stateful
> inspection in front of it, then you deserve your house blinking
> radically at all hours of the day or night…
> 
> However, I said “without any sort of filter”. Not “without a
> host-based filter”, so I’m still unclear on how this is a relevant
> response to what I said.

Then we're on the same page. Thanks for the clarification!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 08:16:16 -0300

On 02/02/2016 06:13 PM, Enno Rey wrote:
>>>>> really not a problem we should be solving at the network
>>>>> level. That's more of an educational problem.
>>>> 
>>> A Stateful inspection firewall that doesn???t mangle the packet
>>> header is perfectly acceptable in an end-to-end world. Whether
>>> it???s a network-level firewall, a host-level firewall, both,
>>> etc.
> 
> state. doing so "in the network" is a - from my understanding -
> fundamental violation of the e2e principle, not least as it impedes
> "survivability in the face of failure".

FWIW, this is what we say in
<https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-01>
about this:

---- cut here ----
3.2.  The End-to-End Principle

   One common complaint about firewalls in general is that they violate
   the End-to-End Principle [Saltzer].  The End-to-End Principle is
   often incorrectly stated as requiring that "application specific
   functions ought to reside in the end nodes of a network rather than
   in intermediary nodes, provided they can be implemented 'completely
   and correctly' in the end nodes" or that "there should be no state in
   the network."  What it actually says is heavily nuanced, and is a
   line of reasoning applicable when considering any two communication
   layers.

      [Saltzer] "presents a design principle that helps guide placement
      of functions among the modules of a distributed computer system.
      The principle, called the end-to-end argument, suggests that
      functions placed at low levels of a system may be redundant or of
      little value when compared with the cost of providing them at that
      low level."

   In other words, the End-to-End Argument is not a prohibition against
   e.g. lower layer retries of transmissions, which can be important in
   certain LAN technologies, nor of the maintenance of state, nor of
   consistent policies imposed for security reasons.  It is, however, a
   plea for simplicity.  Any behavior of a lower communication layer,
   whether found in the same system as the higher layer (and especially
   application) functionality or in a different one, that from the
   perspective of a higher layer introduces inconsistency, complexity,
   or coupling extracts a cost.  That cost may be in user satisfaction,
   difficulty of management or fault diagnosis, difficulty of future
   innovation, reduced performance, or other forms.  Such costs need to
   be clearly and honestly weighed against the benefits expected, and
   used only if the benefit outweighs the cost.

   From that perspective, introduction of a policy that prevents
   communication under an understood set of circumstances, whether it is
   to prevent access to pornographic sites or prevents traffic that can
   be characterized as an attack, does not fail the End-to-End Argument;
   there are any number of possible sites on the network that are
   inaccessible at any given time, and the presence of such a policy is
   easily explained and understood.

   What does fail the End-to-End Argument is behavior that is
   intermittent, difficult to explain, or unpredictable.  If I can
   sometimes reach a site and not at other times, or reach it using this
   host or application but not another, I wonder why that is true, and
   may not even know where to look for the issue.
---- cut here ----

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 08:29:06 -0300

On 02/04/2016 01:26 AM, Owen DeLong wrote:
> First, being unable to find the L4 header because you can’t parse the
> ext. headers shouldn’t happen. Extension headers are all designed with
> standard parameters at the beginning allowing them to be skipped if they
> are not understood.

Not really. Please see:
<https://www.ietf.org/id/draft-gont-6man-rfc6564bis-01.txt>

[....]
> OTOH, if $ISP is blocking packets for their customers that their
> customers would prefer to see, then $ISP is both a different authority
> _AND_ quite thoroughly in the wrong.
> 

+1

Thanks,

---

From: Tim Chown <[email-masked]>
Date: Thu, 4 Feb 2016 12:43:20 +0000

> On 2 Feb 2016, at 18:45, Fred Baker (fred) <[email-masked]> wrote:
> 
> 

I agree. And to me that seems fine - how the host handles the address(es) it uses to initiate or receive traffic is a matter for it, just as host-based filtering / access control is.

Tim

---

From: Owen DeLong <[email-masked]>
Date: Thu, 4 Feb 2016 12:07:34 -0800

Wouldn’t it be simpler just to require all IPv6 extension headers to conform to the NH/HdrExtLen first fields?

I don’t see the point of encapsulating all future extension headers in yet another header.

To the best of my knowledge, all existing extension headers already conform to this syntax. TBH, I thought they were already required to do so.

Owen

> On Feb 4, 2016, at 03:29 , Fernando Gont <[email-masked]> wrote:
> 
> <https://www.ietf.org/id/draft-gont-6man-rfc6564bis-01.txt <https://www.ietf.org/id/draft-gont-6man-rfc6564bis-01.txt>>
> 
> 
> [....]
> e-mail: [email-masked] <mailto:[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 4 Feb 2016 17:33:50 -0300

On 02/04/2016 05:07 PM, Owen DeLong wrote:
> Wouldn’t it be simpler just to require all IPv6 extension headers to
> conform to the NH/HdrExtLen first fields?

You can''t, because the upper-layer protocols and EHs share the same
namespace.

Example: Say you receive unknown NH=88... Is it a new transport
protocol, or a new EH? -- Answer: You just can't tell.

> To the best of my knowledge, all existing extension headers already
> conform to this syntax. TBH, I thought they were already required to do so.

The problem is not existing EHs -- those you can identify, and hence
know how to parse.  The problem is any new EHs or upper-ayer-protocols
defined in the future.