Re: [v6ops] multiple prefixes [no longer draft-ietf-v6ops-ula-usage-recommendations-02.txt]

[Brian E Carpenter <[e-mail]>]

On 22/02/2014 10:48, Ray Hunter wrote:
>> Brian E Carpenter <mailto:[e-mail]>
>> 21 February 2014 20:36
>>> Only authorised machines should communicate.
>>
>> In such a regime you're bound to have stateful or static address
>> assignment, so if you have N prefixes each machine will need to have
>> N stateful or static addresses. I understand that it's N times the
>> hassle and that you might not want to do it.
>>
>> However, an address derived from a ULA prefix would never be
>> authorised to communicate with the Internet. If you had a subclass
>> of machines that were allowed to communicate with a business
>> partner via ULA but not with the Internet, a ULA would just be
>> one of the N.
>>
>> Regards
>>     Brian
> 
> And then maintain correlation of Semantically Opaque Interface
> Identifiers to machine for each prefix?

That seems to be the necessary implication of the restricted access
model that Ray describes, regardless of what kind of prefix or
how many of them you have.

> 
> No thanks.
> 
> I think the only sensible operational advice is "Do not split a ULA /48
> prefix across a firewall or other network security zone boundary"

I agree. That's not the model. If company A has a prefix ULA-A
and company B has a prefix ULA-B, then A announces a route to ULA-A
on the private link between the companies, and B announces ULA-B.

> 
> That way the default address selection rules will ensure that no two
> nodes will use ULA's for communication across that boundary, and you can
> maintain a single ACL/firewall rule based on the GUA RIR registered
> addresses.

You need different rules on the inter-company link.

   Brian

>>
>> On 21/02/2014 23:43, Ray Hunter wrote:
>>>> Brian E Carpenter<mailto:[e-mail]>
>>>> 21 February 2014 01:25
>>>> On 21/02/2014 10:53, Ray Hunter wrote:
>>>>>> Brian E Carpenter<mailto:[e-mail]>
>>>>>> 20 February 2014 21:03
>>>>>> On 20/02/2014 20:40, Ray Hunter wrote:
>>>>>> ...
>>>>>>
>>>>>> Ray, ULA prefixes *are* global unicast prefixes; their only special
>>>>>> characteristic is that they are not routed outside a given
>>>>>> administrative
>>>>>> domain.
>>> OK ULA = Globally unique with high probability of uniqueness, and
>>> limited reachability scope.
>>>
>>> RFC 6887 states "These IP addresses may have distinct reachability
>>> scopes (e.g., if IPv6, they might have global reachability scope as is
>>> the case for a Global Unicast Address (GUA) [RFC3587] or limited scope
>>> as is the case for a Unique Local Address (ULA) [RFC4193])." which
>>> suggests to me that they are distinct.
>>>
>>> And RFC 3587 refers to "The TLA/NLA scheme has been replaced by a
>>> coordinated allocation policy defined by the Regional Internet
>>> Registries (RIRs) [IPV6RIR]" which does not cover self-generated ULA.
>>>
>>> So I'm not the first to blur that particular boundary.
>>>>>> Also, it is common for large enterprises to run multiple disjoint
>>>>>> prefixes
>>>>>> within the corporate network, and has been for many years.
>>>>>>
>>>>> So how do they set up firewall rules?
>>>> I'm not sure why you ask, and when I worked for such a company
>>>> (IBM) it wasn't something I ever looked at. However, I assume
>>>> that the filters for every border device to the Internet cited
>>>> all the internal prefixes in use.
>>> Nope. Especially at private NNI's, the enterprises have a duty to
>>> protect each other from attack by e.g. virus storms.
>>> Only authorised machines should communicate.
>>>
>>>> Certainly the config file for
>>>> the call-home VPN on my company laptop included a very long list of
>>>> prefixes, and I guess that was pretty much the same list as they
>>>> needed in the border firewalls.
>>> Nope. Many businesses have a requirement for controlled and tracked
>>> outbound access. e.g. to see which machine FTPed a copy of the corporate
>>> development code to the Internet, and when.
>>>>>> I think the issues you're concerned about are all due to the fact
>>>>>> that
>>>>>> in IPv6, it is bog standard to run more than one prefix on the same
>>>>>> phsyical subnet. The fact that one of them might be delegated from
>>>>>> a ULA /48 seems to me to be a side issue.
>>>>>>
>>>>>> Brian
>>>>> So you see no problems with a machine running multiple prefixes, where
>>>>> the IID for each may also be different (stable privacy addresses), and
>>>>> each session may source from a different prefix depending on where
>>>>> it's
>>>>> terminating (address selection + address rotation of privacy
>>>>> addresses)?
>>>> That's the design of IPv6.
>>>>
>>>>> How will the firewall even know it's the same machine sending the
>>>>> packets, never mind the same user, so that the communication stream
>>>>> can
>>>>> be authorised or blocked?
>>>> You're talking about a firewall that censors outgoing sessions?
>>> Yes.
>>>> Well, that's bound to be a pain. But you'll find the MAC address
>>>> in the ND cache, so you could check that way.
>>> They are not connected at L2.
>>>>> Will users have to re-authenticate for every prefix + IID combination?
>>>> If it's a firewall that authenticates users, yes, I would think so.
>>>> But I don't see why that would require user action; it should just be
>>>> automatic after the user's initial authentication. If not, the
>>>> authentication mechanism is not well designed for IPv6.
>>>>
>>>>      Brian
>>>>
>>>>
>>> Is there any IETF standard for this authentication?
>>>
>>> When I check PCP it doesn't seem to explicitly correlate requests from
>>> the same machine, and ULA's should not be used as the source of the PCP
>>> message.
>>>> IPv6 addresses without global reachability (e.g., ULAs) SHOULD NOT be
>>> used as the source interface when generating a PCP request.
>>>
>>> What about internal firewalls within an enterprise? ULA only networks?
>>> Ignore the SHOULD?
>>> GUA prefix that arrives after the ULA is configured? Before ULA is
>>> configured?
>>>
>>> I still expect operational issues with synchronising access requests
>>> from a single machine across multiple prefixes:
>>> GUA rule times out, but the ULA rule doesn't or vice versa. It's going
>>> to be a nightmare to debug.
>>>
>>> To my mind, there definitely seems to be operational gaps in the
>>> assumptions made for GUA + ULA operation in parallel.
>>>
>>
>> ------------------------------------------------------------------------
> 
>