Subject: [OPSEC] A Tale of Two Drafts

From: Ronald Bonica <[email-masked]>
Date: Tue, 27 Mar 2012 01:29:39 -0400

Folks,

As part of a thought experiment, assume that the IETF were to publish both of the following drafts:

- draft-behringer-lla-only-00
- draft-baker-opsec-passive-ip-address

An operator, attempting to comply with both recommendations, might configure an interior router with exactly two globally scoped IPv6 addresses. Both addresses would be loopbacks. One address would accept inbound traffic but would never be the source of an ICMP message. The second address would not accept inbound traffic but would be the source of all ICMP messages.

Is this what we want? If so, we should say so explicitly (in one draft or the other, or possibly by merging the drafts).

--------------------------
Ron Bonica
/speaking as individual contributor
vcard:       www.bonica.org/ron/ronbonica.vcf

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Mar 2012 07:39:23 +0200

> Is this what we want? If so, we should say so explicitly (in one draft or the other, or possibly by merging the drafts).

Jason and I were talking later, and came up with an approach that might make sense.

The premise is that you buy that LLAs should be used for routing (Michael's argument, which I agree with), that you like passive addresses for the security purpose, and you want the network manager responsible for the network to be able to traceroute and get active addresses for his purposes.

One approach to implementation would be for a service provider to implement his network with even-odd pairs of subnet prefixes. "Even-Odd" might be trivially understood to mean "pairs of subnets in which bit 63 is zero in one and one in the other"; that is one implementation, but in fact the magic bit could be any of the bits in the subnet part of the address. If there is one major prefix for the network, that would mean that each interface has three addresses - a link-local address for use in routing, a passive address in the even subnet, and an active address in the odd subnet. Under policy control, the responder might respond to traceroute or other messages with the active address if the source address of the datagram is permitted by some access list, and with the passive address otherwise. The impact of doing so would be to enable the administration to debug its own network easily while denying similar access to folks outside the network. In this manner, the passive address (which is included in the general prefix the network advertises in BGP), passes Ingress Filtering checks, but an attack packet gets dropped as soon as it enters the network, as it is forwarded to the network's "covering" route, which is null routed.

A similar implementation approach would take one /64 prefix, null route it throughput the network, and use /128s from that for the passive IP addresses.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 27 Mar 2012 09:32:00 +0200

Indeed, the two I-D are indeed compatible (some co-authors have talked together). Passive-IP could require some code change while LLA is more a configuration thing. Hence, two I-D

-éric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ronald Bonica
> Sent: mardi 27 mars 2012 07:30
> To: [email-masked]
> Subject: [OPSEC] A Tale of Two Drafts
> 
> Folks,
> 
> An operator, attempting to comply with both recommendations, might configure
> an interior router with exactly two globally scoped IPv6 addresses. Both
> addresses would be loopbacks. One address would accept inbound traffic but
> would never be the source of an ICMP message. The second address would not
> accept inbound traffic but would be the source of all ICMP messages.
> 
> Is this what we want? If so, we should say so explicitly (in one draft or
> the other, or possibly by merging the drafts).
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 27 Mar 2012 06:05:47 -0400

Fred,

In the proposal that you describe, does every interface on the router have a globally scoped address or just the loopback?

                                          Ron

> From: Fred Baker [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2012 7:39 AM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: [OPSEC] A Tale of Two Drafts
> 
> 
> > Is this what we want? If so, we should say so explicitly (in one
> draft or the other, or possibly by merging the drafts).
> 
> The premise is that you buy that LLAs should be used for routing
> (Michael's argument, which I agree with), that you like passive
> addresses for the security purpose, and you want the network manager
> responsible for the network to be able to traceroute and get active
> addresses for his purposes.
> 
> One approach to implementation would be for a service provider to
> implement his network with even-odd pairs of subnet prefixes. "Even-
> Odd" might be trivially understood to mean "pairs of subnets in which
> bit 63 is zero in one and one in the other"; that is one
> implementation, but in fact the magic bit could be any of the bits in
> the subnet part of the address. If there is one major prefix for the
> network, that would mean that each interface has three addresses - a
> link-local address for use in routing, a passive address in the even
> subnet, and an active address in the odd subnet. Under policy control,
> the responder might respond to traceroute or other messages with the
> active address if the source address of the datagram is permitted by
> some access list, and with the passive address otherwise. The impact of
> doing so would be to enable the administration to debug its own network
> easily while denying similar access to folks outside the network. In
> this manner, the passive address (which is included in the general
> prefix the network advertises in BGP), passes Ingress Filtering checks,
> but an attack packet gets dropped as soon as it enters the network, as
> it is forwarded to the network's "covering" route, which is null
> routed.
> 
> A similar implementation approach would take one /64 prefix, null route
> it throughput the network, and use /128s from that for the passive IP
> addresses.

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Mar 2012 13:24:00 +0200

> In the proposal that you describe, does every interface on the router have a globally scoped address or just the loopback?

The proposal actually doesn't require that choice - the attribute is on addresses where the operator configures them. Michael's proposal says "only the loopback interface", which in my view means that ICMP messages would use the loopback address as a source and would therefore leave the router open to attack (as would using an ACL - yes, the router can throw away the messages, but its bandwidth and its CPU are expended doing so). I would prefer to make the attack traffic unable to disrupt the router, the address indicative of the interface (putting at least the passive address on the interface if not the active address), and the passive address (and the active) in ip6.arpa. However, if the operator prefers to put the passive and/or active addresses on the loopback interface, that's the operator's option.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Mar 2012 14:10:37 +0200

Hi Fred,

Let me restate my question asked at the mic. 

How do I make an address with the attribute set reachable by my NOC and not by any other NOC ? One of the chairs reposned use ACL but as you say this in not the point of your draft.

Have you consider that your attribute could automatically recognize addresses in the IGP and not make given address as passive for icmp, ssh, smtp from those sources ?

Thx,
R.

---

From: Joel jaeggli <[email-masked]>
Date: Tue, 27 Mar 2012 14:20:04 +0200

On 3/27/12 14:10 , Robert Raszuk wrote:
> How do I make an address with the attribute set reachable by my NOC
> and not by any other NOC ? One of the chairs reposned use ACL but as
> you say this in not the point of your draft.
> 
> Have you consider that your attribute could automatically recognize
> addresses in the IGP and not make given address as passive for icmp,
> ssh, smtp from those sources ?

default and/or very large aggregates frequently appears in IGPs...

> Thx, R.
>>> In the proposal that you describe, does every interface on the
>>> router have a globally scoped address or just the loopback?
>> 
>> The proposal actually doesn't require that choice - the attribute
>> is on addresses where the operator configures them. Michael's
>> proposal says "only the loopback interface", which in my view means
>> that ICMP messages would use the loopback address as a source and
>> would therefore leave the router open to attack (as would using an
>> ACL - yes, the router can throw away the messages, but its
>> bandwidth and its CPU are expended doing so). I would prefer to
>> make the attack traffic unable to disrupt the router, the address
>> indicative of the interface (putting at least the passive address
>> on the interface if not the active address), and the passive
>> address (and the active) in ip6.arpa. However, if the operator
>> prefers to put the passive and/or active addresses on the loopback
>> interface, that's the operator's option.
>> 
>>> Ron
>>> 
>>> 
>>>> -----Original Message----- From: Fred Baker
>>>> [mailto:[email-masked]] Sent: Tuesday, March 27, 2012 7:39 AM 
>>>> To: Ronald Bonica Cc: [email-masked] Subject: Re: [OPSEC] A
>>>> Tale of Two Drafts
>>>> 
>>>> 
>>>> The premise is that you buy that LLAs should be used for
>>>> routing (Michael's argument, which I agree with), that you like
>>>> passive addresses for the security purpose, and you want the
>>>> network manager responsible for the network to be able to
>>>> traceroute and get active addresses for his purposes.
>>>> 
>>>> One approach to implementation would be for a service provider
>>>> to implement his network with even-odd pairs of subnet
>>>> prefixes. "Even- Odd" might be trivially understood to mean
>>>> "pairs of subnets in which bit 63 is zero in one and one in the
>>>> other"; that is one implementation, but in fact the magic bit
>>>> could be any of the bits in the subnet part of the address. If
>>>> there is one major prefix for the network, that would mean that
>>>> each interface has three addresses - a link-local address for
>>>> use in routing, a passive address in the even subnet, and an
>>>> active address in the odd subnet. Under policy control, the
>>>> responder might respond to traceroute or other messages with
>>>> the active address if the source address of the datagram is
>>>> permitted by some access list, and with the passive address
>>>> otherwise. The impact of doing so would be to enable the
>>>> administration to debug its own network easily while denying
>>>> similar access to folks outside the network. In this manner,
>>>> the passive address (which is included in the general prefix
>>>> the network advertises in BGP), passes Ingress Filtering
>>>> checks, but an attack packet gets dropped as soon as it enters
>>>> the network, as it is forwarded to the network's "covering"
>>>> route, which is null routed.
>>>> 
>>>> A similar implementation approach would take one /64 prefix,
>>>> null route it throughput the network, and use /128s from that
>>>> for the passive IP addresses.
>>> 
>> 
>> _______________________________________________ OPSEC mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/opsec
> _______________________________________________ OPSEC mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Mar 2012 14:31:45 +0200

You could use igp tagging and only permit tagged routes to be legitimate src.

R.

---

From: Joel jaeggli <[email-masked]>
Date: Tue, 27 Mar 2012 14:39:07 +0200

> You could use igp tagging and only permit tagged routes to be legitimate src.

indeed

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Mar 2012 14:49:39 +0200

> Have you consider that your attribute could automatically recognize addresses in the IGP and not make given address as passive for icmp, ssh, smtp from those sources ?

Since we're restating things, I'll restate what I said earlier today in this same thread. I get to it by editing the email you sent me...

>>>> it throughput the network, and use /128s from that for the passive IP

Now, let me repeat with pictures. Note that, as I told Ron, I'm not stuck on whether the interface a passive or active address is on is physical or virtual, although I would (if I were implementing it) put passive and perhaps active addresses on physical interfaces so that a traceroute response can identify the interface in question. In this example sketch, I will therefore talk about the physical interface, but it could as easily be virtual with a corresponding loss of information.

Presume that the domain in question is 2001:db8:1::/48, and the "other domain" in question is 2001:db8:2::/48. Taking the second approach above, presume that the prefix 2001:db8:1:ffff::/64 is used for all passive addresses in the target domain. So now every physical interface.

                 _.--------.
             ,-''           `--.                  ,-----.
           ,'                   `.              ,'       `.
         ,'                       `.          ,'           `.
        /                           \        /               \
       /      2001:db8:1::/48        \      / 2001:db8:2::/48 \
      /                               \    ;                   :
     /                                 \   ;                   :
    ;   +-----+  +------+   Traceroute  : ;      +--------+     :
    |   |Host |  |Router|<---------------------- |Attacker|     |
    |   |Alice|  |Bob   | ---------------------->|Carol   |     |
    |   +--+--+  +--+---+ TTL Exp   /----------- +--------+     |
    :   ---+--------+-----         /    ; :                     ;
     \                            /    /   :                   ;
      \                          /    /    :                   ;
       \       Null Route       V    /      \                 /
        \      2001:db8:1:ffff::/64 /        \               /
         `.                       ,'          `.           ,'
           `.                   ,'              `.       ,'
             `--.           _.-'                  `-----'
                 `--------''

Carol wants to DOS Alice's router, Bob, reseting a BGP connection, consuming its bandwidth, or whatever (Carol could simply DOS Alice's address determined from DNS; this approach doesn't address that problem). She starts by doing a traceroute toward Carol to determine Bob's address, followed by a flood toward Bob. The sequence of messages is an ICMP Echo or UDP whatever with a certain TTL, resulting in an ICMP TTL Expired, followed by the flood.

In the model I am suggesting, since the address given to Carol is a null routed address, Carol cannot use it to get a packet to Bob.

Does that help?

---

From: Jared Mauch <[email-masked]>
Date: Tue, 27 Mar 2012 09:32:43 -0400

> Have you consider that your attribute could automatically recognize addresses in the IGP and not make given address as passive for icmp, ssh, smtp from those sources ?

I'm still having trouble with the link-local drafts, but perhaps it's just me…

The principle of least-surprise for the operators of networks tells me that the IPv6 access part should look similar to IPv4 part.  While I can run some aspects of my IPv4 network with 'ip unnumbered' this generally is not the case.

While IPv6 is unique in providing the link-local whereas IPv4 doesn't have, the average consumer/operator is unlikely to employ this technique as it increases the complexity in the network to solve a problem in IPv6 [only] that could be solved with a common IPv4+IPv6 Control Plane Policing Policy/capability.  

Using a different tool to mitigate this risk in IPv4 vs IPv6 concerns me in that it creates unnecessary complexity.

- Jared

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Mar 2012 15:34:11 +0200

Thx Fred.

I was suggesting to avoid "some acl"  to be configured and maintained on all routers but rather then that tag sources in ones igp which are authorized to get proper response from network elements. 

That way your knob can be fully automated yet ease operational aspects.

Btw is this not applicable to ipv4 also ?

Many thx,
R.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 27 Mar 2012 09:37:09 -0400

> Btw is this not applicable to ipv4 also ?

My thought is a solution should be comparable in deployment regardless of the bit length of the address.

- Jared

---

From: Gert Doering <[email-masked]>
Date: Tue, 27 Mar 2012 15:37:21 +0200

Hi,

On Tue, Mar 27, 2012 at 09:32:43AM -0400, Jared Mauch wrote:
> I'm still having trouble with the link-local drafts, but perhaps it's just me?

It's me as well...

I'm so old-fashioned, I like ping, mtr, traceroute, and all the good
stuff that helps me figure out where in my neighbouring networks my
happy packets turn unhappy.  And yes, I know about the shortcomings, 
but it's still better than "take it away completely, because there
are never any problems in my network!".

But I can see that people do like the approach, and I'm fine with that,
as long the final document doesn't tell people "this is the only proper 
way to run your network!" but properly documents reasons for doing so,
and shortcomings.

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

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: Joel jaeggli <[email-masked]>
Date: Tue, 27 Mar 2012 15:45:39 +0200

> Using a different tool to mitigate this risk in IPv4 vs IPv6 concerns me in that it creates unnecessary complexity.

For mitigation of ND issues one can use /127s for point-to-point so
obscuring the link for ND attack avoidance applies to larger subnets but
not the case where you'd get away with ip unumbered ip ipv4.

l2 nets with a number routers or exchange fabrics have somewhat more
complex issues.

---

From: Fred Baker <[email-masked]>
Date: Tue, 27 Mar 2012 15:55:26 +0200

> Btw is this not applicable to ipv4 also ?

I'm mostly thinking about IPv6. But I tried pretty hard to word the draft so that it could be applied to IPv4.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 29 Mar 2012 12:17:38 -0400

Previously on OPSEC:

> way to run your network!" but properly documents reasons for doing so,

[Today in v6ops]

There were some comments today at the mic which I personally take as key.  An operator (I didn't catch who, sorry if you're not on here) spoke about their experience using link-local in their IPv6 deployment.  The experience resulted in it becoming removed from their environment.

----

Personally I would like to see a well-defined problem statement.  In the current form, I don't feel this can be something that moves in the BCP direction and will likely be a footnote/blip in the history of early IPv6 days.

- Jared