Subject: Re: [v6ops] why IPv6 EHs in the Real World

From: Joe Touch <[email-masked]>
Date: Fri, 03 Apr 2015 11:46:49 -0700

On 3/27/2015 8:22 PM, Brian E Carpenter wrote:
>>> I understand the security risk, I think; that’s discussed in RFC
>>> 5095. I’ll note, however, that the RFC doesn’t address “routing
>>> headers”; it addresses “routing headers of type 0”. The Segment
>>> Routing header is a Routing Header, and trashing all Segment
>>> Routing traffic because we have an issue with RH0 traffic seems a
>>> trifle extreme.
>
> This is laid out precisely in RFC 7045*, so you can tell any operator
> that trashes all RH packets that they are in violation and the protocol
> police are very angry with them.
> 
>     Brian

While I appreciate that screaming to operators isn't going to do much,
we need to find a way to encourage the operators to *ask for their money
back* from vendors who claim support for IPv6 but don't actually support
IPv6.

That's the lever we should find a way to pull.

Joe

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Apr 2015 11:18:15 +0200

Le 28/03/2015 04:22, Brian E Carpenter a écrit :
> On 28/03/2015 08:01, Fred Baker (fred) wrote:
>>> I dont work for an Operator, but it is reasonable to expect
>>> operators to filter Routing Headers.
>>>
>>> These are not used by any application and open a signficant
>>> security risk.
>>
>> </chair>
>>
> This is laid out precisely in RFC 7045*, so you can tell any
> operator that trashes all RH packets that they are in violation and
> the protocol police are very angry with them.
>
> Brian
>
> * "The IPv6 Routing Header Types 0 and 1 have been deprecated.  Note
> that Type 0 was deprecated by [RFC5095].  However, this does not
> mean that the IPv6 Routing Header can be unconditionally dropped by
> forwarding nodes.  Packets containing standardised and undeprecated
> Routing Headers SHOULD be forwarded by default.  At the time of
> writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the
> experimental Routing Header Types 253 and 254 [RFC4727].  Others may
> be defined in the future."

Brian,

So currently RH types 2 (Mobile IPv6), 3 (RPL) and 253 and 254 for
experiments are not deprecated andshould be implemented.

In protocole Mobile IPv6 the RH type 2 is used in some cases for Route
Optimization (there are other MIP6 cases).  This feature (RO) needs to
be implemented also in the Correspondent Nodes, not only in the network.
  And, the CNs dont implement RO.  If the CNs dont implement RO then
there is no reason for the network to transmit RH type 2.

Second, for RH type 3 in RPL - this is local-only routing, i.e. a
network of small devices which are typically disconnected from the
Internet.  The RH must contain only addresses within that domain, or let
self do tunnelling instead.

RH types 253 and 254 are EXPERIMENTAL - but there is no experiment
described.  We dont even know whether it is a local experiment or
something that needs to get through Internet overall.

For these reasons, I still suppose data carrying operators have all
reasons to filter RHs altogether.

Alex

>
>>
>> I get a little antsy is it being filtered by a system other than
>> the one in the destination address or a system acting as a
>> firewall. The operator doesn’t necessarily know what network the
>> address is in, or whether there might be a private arrangement
>> between networks that use his network as transit to communicate. I
>> would want the transit domains to not be applying transitive policy
>> to their customer’s or peer’s traffic without their knowledge.
>>
>>
>>
>> _______________________________________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 7 Apr 2015 11:32:13 +0200

Hi,

> reasons to filter RHs altogether.

The only halfway acceptable reason is "I need to drop RH0, but have
stupid gear that cannot differenciate, so either drop-all or drop-none".

(Yes, this happens for brand new top-of-the-line gear...)

Gert Doering
        -- NetMaster
-- 
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 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Apr 2015 12:06:39 +0200

Le 07/04/2015 11:32, Gert Doering a écrit :
>> For these reasons, I still suppose data carrying operators have
>> all reasons to filter RHs altogether.
>

I agree.

This begs a question about particular hardware which may not distinguish
types, and thus force others to drop-all RHs, regardless of their type -
what is that hardware?

Alex

> Gert Doering -- NetMaster
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 7 Apr 2015 14:36:53 +0200

Hi,

> types, and thus force others to drop-all RHs, regardless of their type -

"Hardware+Software".  My current beef is Cisco IOS XR on ASR9001, which
has hardware capable of doing about anything, and software that missed that
particular call...

(Of course there's 6500/Sup720, which has hardware not capable of doing
any EH header filtering, but that is *old* stuff and not particularily
relevant here)

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2015 08:45:33 +1200

>> types, and thus force others to drop-all RHs, regardless of their type -

I don't see which word is hard to understand in "Packets containing
standardised and undeprecated Routing Headers SHOULD be forwarded by
default." That's the IETF standards requirement, and SHOULD means that
"there may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."

Operators are adult enough to do the right thing, but for that to work,
products need to be properly designed.

     Brian

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 09 Apr 2015 22:07:28 +0100

> products need to be properly designed.

products are designed to a budget and a performance spec.  There's no point
in building a router which will inspect 65536 byte packets for EH chains if
it's too expensive for anyone to buy, or if it trashes performance by
passing packets with headers that big.  There is always a
cost/speed/features compromise.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2015 11:58:41 +1200

> cost/speed/features compromise.

Of course. But we already changed the standard to limit this problem:

http://tools.ietf.org/html/rfc7112

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Apr 2015 17:29:31 +0100

> http://tools.ietf.org/html/rfc7112

a policy cannot change reality.  At best it can hope to complement it.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Apr 2015 08:35:36 +1200

> a policy cannot change reality.  At best it can hope to complement it.

True. But fixing our specs and encouraging implementers to do the
right thing are the only tools the IETF has.

    Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 17 Apr 2015 14:49:58 +0200

Le 07/04/2015 14:36, Gert Doering a écrit :
>> This begs a question about particular hardware which may not
>> distinguish types, and thus force others to drop-all RHs,
>> regardless of their type - what is that hardware?
>
> "Hardware+Software".  My current beef is Cisco IOS XR on ASR9001,
> which has hardware capable of doing about anything, and software
> that missed that particular call...
>
> (Of course there's 6500/Sup720, which has hardware not capable of
> doing any EH header filtering, but that is *old* stuff and not
> particularily relevant here)

I agree with that point.

There are 2 problems here: either the operator consciously filters EHs
of a certain kind, or the software on the router is not yet aware of
some recently defined EHs.

One can distinguish betwween the two by checking whether an ICMPv6
parameter problem is issued or not.

In a particular network I am connecting to, an intervening router sends
back an ICMPv6 Parameter Problem with a Pointer field pointing to the
type Home Address of a Destination Options extension header (EH) of a
Binding Update of protocol Mobile IPv6.

Intuitively, that suggests that the router complaining of that EH may be
old, not updated to understand Mobile IPv6 (although the MIP spec is
there for many years and many commercial and oss implementations are out
there since long).

This EH is absolutely necessary to exist in real world to offer the
mobility part of IPv6.  Filtering it consciously does not avoid security
risks (there aren't for MIP non-RO).   It must be allowed.

Alex

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 18 Apr 2015 18:03:44 -0700 (PDT)

> risks (there aren't for MIP non-RO).   It must be allowed.

The obvious question to ask is why in the world an intervening 
router is inspecting stuff inside the Destination Options header in 
the first place (clearly, it has to inspecting the options in order 
to generate an ICMPv6 Parameter Problem with a Pointer field 
pointing to a specific option).  It is hard to see how Destination 
Options (of any kind) would affect the security of the router or of 
the transit network.  If the router imply ignored the header, as 
it's supposed to do (per RFC 7045), then it would not need to be 
updated to recognize new DOs.

//cmh

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 19 Apr 2015 23:17:17 +0200

Le 19/04/2015 03:03, C. M. Heard a écrit :
>> In a particular network I am connecting to, an intervening router
>> sends back an ICMPv6 Parameter Problem with a Pointer field
>> pointing to the type Home Address of a Destination Options
>> extension header (EH) of a Binding Update of protocol Mobile IPv6.
>>
>> Intuitively, that suggests that the router complaining of that EH
>> may be old, not updated to understand Mobile IPv6 (although the
>> MIP spec is there for many years and many commercial and oss
>> implementations are out there since long).
>>
>> mobility part of IPv6.  Filtering it consciously does not avoid
>> security risks (there aren't for MIP non-RO).   It must be
>> allowed.
>
> to generate an ICMPv6 Parameter Problem with a Pointer field pointing
> to a specific option).  It is hard to see how Destination Options
> (of any kind) would affect the security of the router or of the
> transit network.  If the router imply ignored the header, as it's
> supposed to do (per RFC 7045), then it would not need to be updated
> to recognize new DOs.

I agree with you.

It is not normal for an intermediate router to look at anything else
than the Base Header and at the Routing Header.  It should not look at
the Destinations Options header - that is for the destination only (the
computer owning the dst address).

I can guess why it looks at it.   It is because in IPv4 there is no such
distinction between headers and extension headers.  An IPv4 router would
look at everything preceding the payload, and thus an IPv6 port would do
the same.  It's just a guess, I may be wrong.

Alex