Subject: [OPSEC] draft-ietf-opsec-ipv6-eh-filtering-06

From: "R. Atkinson" <[email-masked]>
Date: Fri, 6 Jul 2018 09:43:09 -0400

Fernando,

Regarding this draft, I have some feedback with respect to CALIPSO
(in part because I am one of the co-authors of RFC-5570, which specifies
CALIPSO).

1. Section 4.3.9 makes an incorrect assumption.

  Contrary to 4.3.9.5, an intermediate system (e.g., IP router) has no method
  to learn or know whether or not it is deployed in an MLS-enabled environment.

  An MLS-enabled IPv6 environment might well be using globally routable
  addresses, so the routing prefixes in use are not informative about the
  deployment type.

  Further, the majority of routers in an MLS-enabled environment are ordinary
  commercial off-the-shelf IP routers from the usual IP router vendors.  Some
  routers and firewalls in such environments might have MLS-enhancements, 
  but many more will NOT have MLS-enhancements.  This is partly because
  the MLS-enabled label enforcement only is needed at enclave boundaries.

  Explicit configuration is the only method via which a particular deployed
  intermediate system can learn whether or not it is in an MLS-enabled
  network environment.  This is sad, but also is reality.

  SUGGESTED ADDITIONAL TEXT for 4.3.9.1:

  "Explicit configuration is the only method via which a particular deployed
  intermediate system can learn whether or not it is in an MLS-enabled
  network environment."

2. As a result, the advice in 4.3.9.5 is not good or correct.  Incorrect assumption
    above leads to an incorrect conclusion about advice on option handling.

   My suggestion is to revise the advice in 4.3.9.5.

  PROPOSED REPLACEMENT TEXT for 4.3.9.5:

  “Intermediate systems that do not implement RFC-5570 SHOULD have 
   a configuration option to EITHER (a) drop packets containing the 
   CALIPSO option OR  (b) to ignore the presence of the CALIPSO option
   and forward the packets normally.”

  “Intermediate systems that do implement RFC-5570 SHOULD have both
   configuration options (a) and (b) from the preceding paragraph and 
   also a third configuration option (c) to process packets containing
   a CALIPSO option as per RFC-5570."

   "Such configuration is the only method via which an intermediate system
   can know whether or not that particular intermediate system has been 
   deployed within an MLS-enabled environment.  In many cases, ordinary 
   commercial intermediate systems (e.g.,  IPv6 routers & firewalls) are the 
   majority of the deployed intermediate systems inside an MLS-enabled 
   network environment."
 
Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Jul 2018 16:41:55 +0200

Hello, Ran,

I realize that you had sent feedback on this topic before, but for sme
reason I had missed it -- my apologies for that!

Please find my comments in-line....

>   network environment.  This is sad, but also is reality.

Question: would you argue that this would warrant forwarding them at
transit routers?

(I ask because while the answer to this question would most likely be
"yes" if within a domain, I bet at a transit router it would be better
to drop the MLS traffic to avoid leaks?) -- please see the applicability
statement in Section 2.2.

>   intermediate system can learn whether or not it is in an MLS-enabled

We will incorporate this. Thanks for suggesting text!

>    and forward the packets normally.”

A couple of questions here:
* What would you argue that de default value of this knob should be?

* In any case, I'd somehow rephrase the advice, since it implies a
requirement for a CALIPSO-specific knob --while we don't require any
option-specific knob for any other option.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "R. Atkinson" <[email-masked]>
Date: Fri, 6 Jul 2018 11:49:22 -0400

> On Jul 6, 2018, at 10:41, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Ran,
> 

Hmm.  Good question.

At least in principle, there might be MLS-enabled network environments
with more than one AS in use.  I do not have data on whether those actually
exist today or not.

Separately, how does a given deployed IP router learn/know that it is
a transit router ?  

Merely running BGP does not imply that it is a transit router.

Merely not running BGP does not imply that it is not a transit router.
(It could be a transit router in an MPLS-centric BGP-free-core backbone.)

For clarity, might the Title of the I-D be changed to something like this:

	Recommendations on the Filtering of IPv6 Packets 
	Containing IPv6 Extension Headers at Transit Routers

> We will incorporate this. Thanks for suggesting text!

Thanks.

> * What would you argue that de default value of this knob should be?

I do not really care either way about the default value, provided that there
is a knob.

> option-specific knob for any other option.

A. Well, this partly goes back to my question towards the top:
	How does a particular router figure out whether it is a transit router ?

  I’ve built IP routers at more than one company, and did Cisco’s initial IPv6
  router implementation.  If there are no knobs in the router/IS configuration,
  then how does the router know whether to apply the advice here (because
  it IS a transit router) or NOT to apply the advice here (because it is NOT a
  transit router).

B. For the other part, please let me observe that at the top of Page 5, the 
    current draft’s text reads in part:

    "We recommend that configuration options are made available to govern
     the processing of each IPv6 EH type and each IPv6 option type.  Such
     configuration options may include the following possible settings: […] "

  The text I proposed for 4.3.9.5 to me seems __very consistent__ with the 
  __existing__ text at the top of page 5 — since that text says that configuration
  knobs are recommended and outlines 2 of the 3 configuration choices 
  that I propose to document.  My proposed text used “SHOULD” which is 
  consistent with the word “recommend” at the top of page 5.  

  Also, “SHOULD” is different from “MUST”.  To my mind, the word “require”
  is different from “recommend” and “require” would map to “MUST” rather
  than to “SHOULD”.  

  In practice, most (all ?) of us realize that any guidance that is neither “MUST”
  nor “MUST NOT” might or might be followed by a conforming implementation 
  of an IETF standards-track RFC.  My goal is simply to offer the best advice 
  to a (possibly naive) implementer who is not active in IETF, is not reading 
  IETF mailing list archives for context, and simply has been told to “implement 
  RFC-wxyz in our intermediate system because customer A asked for it”.
  There are HUGE numbers of implementers of mainstream commercial
  products who aren’t active in IETF and simply write code from the RFC.

  I  do fully understand that (at least for some common implementations) the
  presence of a Hop-by-Hop Header can create a (D)DOS attack vector on
  the control plane (for some common router implementations).  Having the
  configuration knob (which again, is consistent with existing text at the top 
  of page 5), allows for the desire/need to drop packets with Hop-by-Hop 
  headers while also allows for the desire/need to ignore those packets
  (or to process them following the RFC-5570 specification).

My apologies for the lengthy answers.  Does that answer the question ?

Yours,

Ran

<off-topic rant>  :-)
PS:  At a former employer, we had packet forwarding silicon that could
be configured either to ignore xor to honor any Hop-by-Hop options that
appeared in an IPv6 packets.  The Verilog to do this was pretty simple.  
Adding that Verilog did not increase the die size or adversely impact our 
layout/place time & costs.  As a customer, I’d much rather buy a router 
with packet forwarding silicon that had such a knob.  Other than on 
very low speed links (e.g., VSAT SATCOM often are Kbps),  I want
to buy routers that use silicon to forward packets, not a CPU, and
with silicon robust against various kinds of (now all too predictable)
(D)DOS attacks.  :-)
</off-topic rant>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Jul 2018 18:24:22 +0200

> with more than one AS in use.  I do not have data on whether those actually

I guess that in those cases the operator could decide to "pass" those
packets?

> (It could be a transit router in an MPLS-centric BGP-free-core backbone.)

Agreed. I'm not saying the router would detect the scenario and filter
accordingly, but rather that the advice applies in such cases. i.e., the
folk reading this doc know that this advice is meant only for such
scenarios.

> 	Containing IPv6 Extension Headers at Transit Routers

I have no issues myself. Will ask the chairs about it.

>   it IS a transit router) or NOT to apply the advice here (because it is NOT a

The goal is that the operator will apply the advice depending on where
the router is being deployed.

>   consistent with the word “recommend” at the top of page 5.  

Yes, my bad.

[....]
> My apologies for the lengthy answers.

Quite the contrary! -- Thans so much for your elaborate anwers!

>  Does that answer the question ?

It does. :-) (agreed on making the knob available)

Regarding the advice, I'm wondering what would be the recommended advice
for transit routers.  I guess it would be "drop, unless it's a MLS
network", with the operator applying this configuration (and hence
knowing what's the context in which this device s operating)

Thoughts?

> with silicon robust against various kinds of (now all too predictable)

Agreed :-)

Thanks a lot!

Cheers,

---

From: "R. Atkinson" <[email-masked]>
Date: Fri, 6 Jul 2018 13:57:03 -0400

> On Jul 6, 2018, at 12:24, Fernando Gont <[email-masked]> wrote:

Fernando,

I don’t think "transit router true/false” is the variable that would determine
whether to drop CALIPSO packets or not.  Instead, it is “MLS enabled 
true/false” that would determine whether to drop.

I am open to word-smithing/editing, but here is some candidate revised 
replacement text for 4.3.9.5 based on today’s email:

  "Recommendations for handling the CALIPSO option depend  on the 
   deployment environment, rather than whether an intermediate system 
   happens to be deployed as a transit device (e.g., IPv6 transit router)."

   “Explicit configuration is the only method via which an intermediate system
  can know whether or not that particular intermediate system has been 
  deployed within a Multi-Level Secure (MLS) environment.  In many cases, 
  ordinary commercial intermediate systems (e.g.,  IPv6 routers & firewalls) 
  are the majority of the deployed intermediate systems inside an MLS 
  network environment.  

 “For Intermediate systems that DO NOT implement RFC-5570, there 
  SHOULD be a configuration option to EITHER (a) drop packets containing 
  the CALIPSO option OR  (b) to ignore the presence of the CALIPSO option
  and forward the packets normally.  In non-MLS environments, such
  intermediate systems SHOULD have this configuration option set to (a)
  above.  In MLS environments, such intermediate systems SHOULD
  have this option set to (b) above.  The default setting for this configuration
  option SHOULD be set to (a) above, because MLS environments are much
  less common than non-MLS environments."

  “For Intermediate systems that DO implement RFC-5570, there SHOULD 
  be configuration options (a) and (b) from the preceding paragraph and 
  also a third configuration option (c) to process packets containing
  a CALIPSO option as per RFC-5570.  When deployed in non-MLS
  environments, such intermediate systems SHOULD have this configuration
  option set to (a) above.  When deployed in MLS environments, such
  intermediate systems SHOULD have this set to (c).  The default setting
  for this configuration option MAY be set to (a) above, because MLS 
  environments are much less common than non-MLS environments."

Thanks very much.

Yours,

Ran

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 Jul 2018 11:45:18 +0200

Hello, Ran,

Apologies for the delay in my response...

> true/false” that would determine whether to drop.

Point taken. (A side question, for my own personal interest: If you have
an MLS environment, wouldn't it be your bet that transit drops your
packets -- i.e., they are *transit*)

>   environments are much less common than non-MLS environments."

The text looks great, and I will incorporate it in the next rev- If any
folks have any objections please do let us know.

Thanks so much, Ran!

Cheers,