Subject: Re: [v6ops] ULA Usage Guide draft requesting for review

From: "Marksteiner, Stefan" <[email-masked]>
Date: Fri, 1 Mar 2013 10:35:56 +0100

Hi,

Section 2.2.2.1 follows the principle "internal addresses for internal communication". As they are (per default) not advertised, they may prevent that internal services become publically available by misconfigurations. Additionally, by their distinctive prefix, they are easier to recognize (for operator eyes) and thus may be easier to troubleshoot in firewalling rules and network sniffers (if, for instance, a service is mistakenly opened to the outside).

Sincerely,

Stefan

P.S.: Even there is a wide consensus that ULAs (or RFC1918-addresses in v4), I personally would broaden the suggestion in 2.2.2.1 to internal infrastructure devices and services for the reasons stated above. If the internal services don't have to be routed (or reside in an extra vlan),  I'd don't number them with GUAs at all and just use their LLAs, which spares a little bit of numbering efforts.

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Owen DeLong
Gesendet: Freitag, 01. März 2013 10:03
An: Liubing (Leo)
Cc: [email-masked]
Betreff: Re: [v6ops] ULA Usage Guide draft requesting for review

> 
>> Section 2.2.2.1
>> 
>> IMHO, this section should be deleted in its entirety or at least come 
>> with a strong cautionary note that such designs are ill-conceived and 
>> detrimental in nature. Pretending that NAT or NPT improve security at all is dubious at best.
>> In fact, NPT and especially NAT provide more tall weeds for attackers 
>> to hide in, if anything.
> 
> [Bing] Such designs come from special requirements such as the abovementioned information security sensitive enterprises or governments. If you want the endpoints disconnected as default and only connected via central control, it is quite reasonable to pick ULA+Proxy. 
> However, normally we won't recommend to use ULA in this model. But I think it might not be proper to justify such scenarios as ill. My point is: if you really have special requirements, just use it in this model; but please don't misunderstanding ULA was just designed for this kind of use.
> 

Then clarify that this is only intended to address ULA on default-disconnected + Proxy networks and _NOT_ NAT or NPT which should never be used with ULA.

>> AL Proxies can be implemented equally effectively using GUA and there 
>> is no significant advantage to ULA in such a case.
> 
> [Bing] If require endpoints default disconnected, egress filtering would be easier and more stable for ULA than GUA. And can save some operation to apply PA/PI.
> 

I disagree. I can filter 2001:db8::/32 just as easily as I can filter fc00::7.

Either way, it's just an entry in a prefix list.

By definition, ULA isn't in any default prefix lists or hard coded into being blocked by routers, so there are no special global default semantics to it that distinguish it from GUA. Only human convention.

>> 
>> Section 3.1
>> 
>> The last sentence should be deleted. GUA is an equally viable option 
>> for these networks.
>> 
>> Section 3.3.2
>> 
>> I'm unable to decipher Paragraph 2, so I cannot make a suggestion on 
>> rewording it. However, since I can't tell what you're trying to say, 
>> I'm pretty sure it needs to be rewritten.
> 
> [Bing] It is only a corner case, that is, if the NAT64 prefix is shorter than 48/, it would divide the 40bit of ULA into two parts. But in most of the practices NAT64 just use 96/. I'll rewritten it for ease of reading. 
> 

That's probably best addressed in a document that says "If you're going to do NAT-64, then don't use a prefix shorter than /48". Certainly there's no need to do so.

Thanks,

Owen

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

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Mar 2013 18:45:25 -0800

> Section 2.2.2.1 follows the principle "internal addresses for internal communication". As they are (per default) not advertised, they may prevent that internal services become publically available…

I'm not sure what you mean by "As they are (per default) not advertised..."

There is no special treatment of ULA in routers. No prefix is advertised in BGP by default. ULA or GUA.
In other protocols, ULA is advertised with the same defaults as GUA.

If I have a local convention that says 2001:123::/32 is my publicly reachable space and 2620:4:104::/48 shouldn't be advertised, it's every bit as recognizable as ULA to the operators that work for me.

> P.S.: Even there is a wide consensus that ULAs (or RFC1918-addresses in v4), I personally would broaden the suggestion in 2.2.2.1 to internal infrastructure devices and services for the reasons sta…

Your DNS must be fun and you've rendered them unreachable to other internal hosts that are not on the same subnet.

Owen

---

From: "Marksteiner, Stefan" <[email-masked]>
Date: Tue, 5 Mar 2013 15:40:29 +0100

Hi,

>If I have a local convention that says 2001:123::/32 is my publicly reachable space and 2620:4:104::/48 shouldn't be advertised, it's every bit as recognizable as ULA to the operators that work for…

What I've meant was just that your provider will propagate your GUA ranges (or, more precisely, the shorter prefixes that contain these ranges). This is not (or should not be) the case for ULA address ranges, so they won't be reachable from the Internet even if you screw up your security configuration (ULAs of course replace, to which I totally agree, by no means any security mechanism - I just think of it as an additional  "insurance against mishaps").

As for the recognition, you're probably right. The only one for whom ULAs are maybe easier to recognize will be a new guy in an operator team.

Besides of whether ULAs are useful for this purpose or not, do you think there are any negative impacts of using ULAs for addressing internal machines (strictly internal - who are never ever  to be reached from the outside, that is).

>Your DNS must be fun and you've rendered them unreachable to other internal hosts that are not on the same subnet.

I thought about SMB companies, which are too small for sensible net segmentation, so they can use LLAs the exact same way as ULAs (except for the fact that they are mandatory according to RFC4291 and its predecessors) or reside in an extra VLAN, in which case they will be orphaned on purpose - I think of a completely isolated management VLAN for infrastructure devices such as switches, etc.  As for the DNS, we have an external and an internal zone, whereas the latter of which is the natural home of the (of course non-autoconfig) LLA-IIDs.

>Owen

Cheers,

Stefan

>>>> IMHO, this section should be deleted in its entirety or at least 
>>>> come with a strong cautionary note that such designs are 
>>>> ill-conceived and detrimental in nature. Pretending that NAT or NPT improve security at all is dubious at best.
>>>> In fact, NPT and especially NAT provide more tall weeds for 
>>>> attackers to hide in, if anything.
>>> 
>>>> AL Proxies can be implemented equally effectively using GUA and 
>>>> there is no significant advantage to ULA in such a case.
>>>

---

From: Owen DeLong <[email-masked]>
Date: Tue, 5 Mar 2013 17:12:22 -0800

> What I've meant was just that your provider will propagate your GUA ranges (or, more precisely, the shorter prefixes that contain these ranges). This is not (or should not be) the case for ULA addr…

Unless of course the attacker finds a way to send a directed packet to a router or other device that has both our ULA and GUA through other means (such as hiding it in a Teredo payload, delivering it to a 6to4 gateway running on someone's laptop, passing it through your stateless NPT, etc.)

Given the myriad ways in which this particular form of phalanx looks more like swiss cheese, I think that the illusion of default security is usually more damaging to security than the thin veil of potential additional protection it might provide under idealized circumstances. Indeed, in my experience, environments that depend on "unreachable addressing" as part of their "defense in depth" tend to be less vigilant about their other security measures and are more likely to "screw up their security configuration".

> As for the recognition, you're probably right. The only one for whom ULAs are maybe easier to recognize will be a new guy in an operator team.

Maybe for a week or so.

> Besides of whether ULAs are useful for this purpose or not, do you think there are any negative impacts of using ULAs for addressing internal machines (strictly internal - who are never ever  to be…

Several. First, forever is a very long time, especially on the internet. Thousands of things we swore just 10 years ago would never remotely consider being attached to the internet are today (whether we realize it or not). I know of at least one large federal agency responsible for  quite a few medical patients that wants to put implanted medical devices in their patients on the IPv6 internet. (Yes, they do seem to be approaching this with due regard for the security considerations, but when they were planning to do this with a "private network with air gap" (which wasn't), they were largely ignoring this.).

As such, it will make things more difficult and likely less secure when these things are eventually put on the internet or start talking to systems that talk to the internet.

Remember, if A trusts B and B trusts C, then A trusts C whether A knows it or not.

If your ULA host trusts a host B that has both ULA and GUA and B trusts {whatever nightmare works for you},
then, your ULA host isn't as isolated as you assumed it was and the distinction between ULA and GUA just became virtually meaningless. However, in your mind and the minds of most of your administrators, it's still an isolated system not attached to the internet with all the assumptions that implies.

OTOH, if it has a GUA prefix, then the second it starts talking to something else that _IS_ on the internet, everyone readily recognizes the risks for what they are.

This, among other reasons,  is why I say that ULA, RFC-1918, NAT not only do not enhance security, they are actually detrimental because of the human factors paradigm shift and shifting assumptions that come with them.

> I thought about SMB companies, which are too small for sensible net segmentation, so they can use LLAs the exact same way as ULAs (except for the fact that they are mandatory according to RFC4291 a…

I don't know what too small for sensible net segmentation would be. Most of my SMB clients have wanted to be able to have a Wifi network that visitors can use, a wired network for employees and internal systems, and a Wifi network for employees. That's three sensible network segments I've implemented in organizations as small as 3 people, 1 cash register and 1 server (plus other more transient devices, mostly in the BYOD category).

It's hard for me to imagine an SMB much smaller than that unless you go to my one-man consulting firm, but the network there is actually quite a bit more complex and has 5 or more segments, depending on the day.

Owen

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 05 Mar 2013 22:47:07 -0500

On 2013-03-05 8:12 PM, "Owen DeLong" <[email-masked]> wrote:

>
>Unless of course the attacker finds a way to send a directed packet to a
>router or other device that has both our ULA and GUA through other means
>(such as hiding it in a Teredo payload, delivering it to a 6to4 gateway
>running on someone's laptop, passing it through your stateless NPT, etc.)

Sure, possible.  Can happen with GUAs or ULAs I guess.  Not sure if using
ULAs makes this more likely to happen.

>
>Given the myriad ways in which this particular form of phalanx looks more
>like swiss cheese, I think that the illusion of default security is
>usually more damaging to security than the thin veil of potential
>additional protection it might provide under idealized circumstances.

I am not sure I buy into this reasoning.  I do agree the some may
incorrectly believe that filtering and/or unreachability alone may be
enough (bad), but I don't think you can assume this will be true.  Also,
the same can exist if using GUAs.  I suspect if engineering and operations
folks are apt to making such assumptions, the block type the architect
picks may not change that behavior.

>Indeed, in my experience, environments that depend on "unreachable
>addressing" as part of their "defense in depth" tend to be less vigilant
>about their other security measures and are more likely to "screw up
>their security configuration".

This is a far reaching statement.

>
>> Besides of whether ULAs are useful for this purpose or not, do you
>>think there are any negative impacts of using ULAs for addressing
>>internal machines (strictly internal - who are never ever  to be reached
>>from the outside, that is).
>
>Several. First, forever is a very long time, especially on the internet.
>Thousands of things we swore just 10 years ago would never remotely
>consider being attached to the internet are today (whether we realize it
>or not). I know of at least one large federal agency responsible for
>quite a few medical patients that wants to put implanted medical devices
>in their patients on the IPv6 internet. (Yes, they do seem to be
>approaching this with due regard for the security considerations, but
>when they were planning to do this with a "private network with air gap"
>(which wasn't), they were largely ignoring this.).

Due diligence needs to be conducted up front to evaluate the potential or
eventual need for global connectivity vs. the choices and risks of using
GUA or ULA.  I can also name a number of things that where not connected
to the Internet  years ago and still aren't.  By extension, there are
things I know of that were thought to need global connectivity and
actually don't.

I think it's an assumption that the use of IP on a given device or system
inherently means it requires Internet access.  As noted before on the
tread, I know of very clear use cases where devices have very defined,
closed circuit connectivity requirements, and will continue to be so for
the system's lifecycle.

>
>As such, it will make things more difficult and likely less secure when
>these things are eventually put on the internet or start talking to
>systems that talk to the internet.

I am not sure you can say this makes it less secure.  Perhaps it makes it
(potentially) annoying and/or expensive to re-address or hack at getting
it connected later.

>Remember, if A trusts B and B trusts C, then A trusts C whether A knows

This is true for GUA and ULA.

>
>This, among other reasons,  is why I say that ULA, RFC-1918, NAT not only
>do not enhance security, they are actually detrimental because of the
>human factors paradigm shift and shifting assumptions that come with them.

I will need to disagree with this statement.  First, ULA != RFC1918.
Also, using RFC1918 and/or ULA does not mean you will be using NAT (It may
be true for some cases, but not all).

I don't think we can postulate that the use of ULAs means that one will
have less security or pay less attention then when using GUA.  Good
security design and operational practices is just that - good security
design and operation practices.  People who make errors, make assumptions
during operation and are not thorough will act this way irrespective of
what address type is assigned (that's not a technical problem related to
address type choice).

I will also say that I do agree with previous statements that standard
filtering and policy rules are simpler when well known ranges can be
applied (based on my experience).  I also think there is validity in the
notion that if both sides protect against the same ranges, we have a
greater expectation of keeping things separated.  Sure stuff gets
configured incorrectly, and it's possible both sides mess up.  But I
don¹t' see how this is more likely by using ULAs vs GUA. (I have seen as
mean errors in production related to global Ips vs. RFC1918 vs. ULAs).  I
do however think if two sides are protecting against different ranges,
there is a greater likelyhood of spillage (given that only one side needs
to mess up).

In the end, I am not saying everyone should use ULAs, and that ULAs are
some type of swiss army knife tool; however I think there is a place for
them with valid use cases.

Regards,

Victor K

---

From: "Marksteiner, Stefan" <[email-masked]>
Date: Wed, 6 Mar 2013 18:02:31 +0100

Hi,

firstly I want to recall, that I don't want to replace any security measure whatsoever by private addressing (as the trust argument below might suggest), but only to use it additionally to use it as a (yes, very thin) "coating on the armor", whereas a botched firewall rule might be the "rust" against which it is protecting (and yes again, protecting is a strong word for that) .  Of course it could be circumvented, it just wanted to say that if you deploy security techniques at perimeter and LAN-level, it might be a good idea to do something on an organizational or network design level as well. IMHO, every layer of protection, as thin as it might be, helps.

That being said, I must state that I'm not so afraid of giving a false sense of security by using ULAs. People who are tricked to thinking they are safe this way are the same people who think security is done by installing a firewall, you can't help them anyway. Generating awareness is (and always was) the most crucial thing when it comes to security - but this shouldn't affect the fact that every tiny step towards a more secure network might actually help (even if it's only to back up little flaws), the more as it is a step that doesn't cost anything (which is always the strongest enemy of security). 

I'm of course totally with you in terms of nobody should RELY on methods which were never intended to be security features.

Cheers,

Stefan

> Von: Owen DeLong [mailto:[email-masked]]
> Gesendet: Mittwoch, 06. März 2013 02:12
> An: Marksteiner, Stefan
> Cc: [email-masked]'
> >>> Section 2.2.2.1 follows the principle "internal addresses for internal
> communication". As they are (per default) not advertised, they may prevent
> that internal services become publically available by misconfigurations.
> Additionally, by their distinctive prefix, they are easier to recognize (for
> operator eyes) and thus may be easier to troubleshoot in firewalling rules
> and network sniffers (if, for  instance, a service is mistakenly opened to the
> outside).
> >>
> >>
> >> If I have a local convention that says 2001:123::/32 is my publicly reachable
> space and 2620:4:104::/48 shouldn't be advertised, it's every bit as
> recognizable as ULA to the operators that work for me.
> >>
> >
> >
> > What I've meant was just that your provider will propagate your GUA
> ranges (or, more precisely, the shorter prefixes that contain these ranges).
> This is not (or should not be) the case for ULA address ranges, so they won't
> be reachable from the Internet even if you screw up your security
> configuration (ULAs of course replace, to which I totally agree, by no means
> any security mechanism - I just think of it as an additional  "insurance against
> mishaps").
> 
> (such as hiding it in a Teredo payload, delivering it to a 6to4 gateway running
> on someone's laptop, passing it through your stateless NPT, etc.)
> 
> like swiss cheese, I think that the illusion of default security is usually more
> damaging to security than the thin veil of potential additional protection it
> might provide under idealized circumstances. Indeed, in my experience,
> environments that depend on "unreachable addressing" as part of their
> "defense in depth" tend to be less vigilant about their other security
> measures and are more likely to "screw up their security configuration".
> 
> > As for the recognition, you're probably right. The only one for whom ULAs
> are maybe easier to recognize will be a new guy in an operator team.
> 
> Maybe for a week or so.
> 
> > Besides of whether ULAs are useful for this purpose or not, do you think
> there are any negative impacts of using ULAs for addressing internal
> machines (strictly internal - who are never ever  to be reached from the
> outside, that is).
> 
> consider being attached to the internet are today (whether we realize it or
> not). I know of at least one large federal agency responsible for  quite a few
> medical patients that wants to put implanted medical devices in their
> patients on the IPv6 internet. (Yes, they do seem to be approaching this with
> due regard for the security considerations, but when they were planning to
> do this with a "private network with air gap" (which wasn't), they were
> largely ignoring this.).
> 
> As such, it will make things more difficult and likely less secure when these
> things are eventually put on the internet or start talking to systems that talk
> to the internet.
> 
> If your ULA host trusts a host B that has both ULA and GUA and B trusts
> {whatever nightmare works for you}, then, your ULA host isn't as isolated as
> you assumed it was and the distinction between ULA and GUA just became
> virtually meaningless. However, in your mind and the minds of most of your
> administrators, it's still an isolated system not attached to the internet with
> all the assumptions that implies.
> 
> OTOH, if it has a GUA prefix, then the second it starts talking to something
> else that _IS_ on the internet, everyone readily recognizes the risks for what
> they are.
> 
> This, among other reasons,  is why I say that ULA, RFC-1918, NAT not only do
> not enhance security, they are actually detrimental because of the human
> factors paradigm shift and shifting assumptions that come with them.
> 
> >>> Sincerely,
> >>>
> >>> Stefan
> >>>
> >>> P.S.: Even there is a wide consensus that ULAs (or RFC1918-addresses in
> v4), I personally would broaden the suggestion in 2.2.2.1 to internal
> infrastructure devices and services for the reasons stated above. If the
> internal services don't have to be routed (or reside in an extra vlan),  I'd don't
> number them with GUAs at all and just use their LLAs, which spares a little bit
> of numbering efforts.
> >>
> >>
> >> Your DNS must be fun and you've rendered them unreachable to other
> internal hosts that are not on the same subnet.
> >
> >
> > I thought about SMB companies, which are too small for sensible net
> segmentation, so they can use LLAs the exact same way as ULAs (except for
> the fact that they are mandatory according to RFC4291 and its predecessors)
> or reside in an extra VLAN, in which case they will be orphaned on purpose - I
> think of a completely isolated management VLAN for infrastructure devices
> such as switches, etc.  As for the DNS, we have an external and an internal
> zone, whereas the latter of which is the natural home of the (of course non-
> autoconfig) LLA-IIDs.
> 
> I don't know what too small for sensible net segmentation would be. Most of
> my SMB clients have wanted to be able to have a Wifi network that visitors
> can use, a wired network for employees and internal systems, and a Wifi
> network for employees. That's three sensible network segments I've
> implemented in organizations as small as 3 people, 1 cash register and 1
> server (plus other more transient devices, mostly in the BYOD category).
> 
> It's hard for me to imagine an SMB much smaller than that unless you go to
> my one-man consulting firm, but the network there is actually quite a bit
> more complex and has 5 or more segments, depending on the day.
> 
> 
> Owen
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Mar 2013 11:34:08 +1100

In message <[email-masked]>, "M
arksteiner, Stefan" writes:
> Hi,
> 
> firstly I want to recall, that I don't want to replace any security 
> measure whatsoever by private addressing (as the trust argument below 
> might suggest), but only to use it additionally to use it as a (yes, very 
> thin) "coating on the armor", whereas a botched firewall rule might be 
> the "rust" against which it is protecting (and yes again, protecting is a 
> strong word for that) .  Of course it could be circumvented, it just 
> wanted to say that if you deploy security techniques at perimeter and 
> LAN-level, it might be a good idea to do something on an organizational 
> or network design level as well. IMHO, every layer of protection, as thin 
> as it might be, helps.
> 
> That being said, I must state that I'm not so afraid of giving a false 
> sense of security by using ULAs. People who are tricked to thinking they 
> are safe this way are the same people who think security is done by 
> installing a firewall, you can't help them anyway. Generating awareness 
> is (and always was) the most crucial thing when it comes to security - 
> but this shouldn't affect the fact that every tiny step towards a more 
> secure network might actually help (even if it's only to back up little 
> flaws), the more as it is a step that doesn't cost anything (which is 
> always the strongest enemy of security). 

If NAT didn't have a continual on going costs on everyone in the
industry you would be seeing less objections.  NAT is like lead in
petrol.  You needed it once.  You don't need it now.  NAT is a toxic
pollutant.

> I'm of course totally with you in terms of nobody should RELY on methods 
> which were never intended to be security features.
> 
> Cheers,
> 
> Stefan
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Marksteiner, Stefan" <[email-masked]>
Date: Thu, 7 Mar 2013 17:18:43 +0100

> Von: Mark Andrews [mailto:[email-masked]]
> Gesendet: Donnerstag, 07. März 2013 01:34
> An: Marksteiner, Stefan
> Cc: 'Owen DeLong'; 'Victor Kuarsingh'; [email-masked]'
> In message
> <[email-masked]>,
> "M arksteiner, Stefan" writes:
> > Hi,
> >
> > the "rust" against which it is protecting (and yes again, protecting
> > is a strong word for that) .  Of course it could be circumvented, it
> > just wanted to say that if you deploy security techniques at perimeter
> > and LAN-level, it might be a good idea to do something on an
> > organizational or network design level as well. IMHO, every layer of
> > protection, as thin as it might be, helps.
> >
> > sense of security by using ULAs. People who are tricked to thinking
> > they are safe this way are the same people who think security is done
> > by installing a firewall, you can't help them anyway. Generating
> > awareness is (and always was) the most crucial thing when it comes to
> > security - but this shouldn't affect the fact that every tiny step
> > towards a more secure network might actually help (even if it's only
> > to back up little flaws), the more as it is a step that doesn't cost
> > anything (which is always the strongest enemy of security).
> 
> If NAT didn't have a continual on going costs on everyone in the industry you
> would be seeing less objections.  NAT is like lead in petrol.  You needed it
> once.  You don't need it now.  NAT is a toxic pollutant.
> 

I agree totally. But I'm not talking about NAT, instead rather about using private addresses which should not be translated intentionally.
I don't use NAT in v4 and I certainly don't intent to use NAT in v6, so IMHO you are completely right.

> > I'm of course totally with you in terms of nobody should RELY on
> > methods which were never intended to be security features.
> >
> > Cheers,
> >
> > Stefan
> >
> 
> --
> Mark Andrews, ISC