Subject: [lisp] Spencer Dawkins' No Objection on draft-ietf-lisp-impact-04: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 21 Oct 2015 09:42:42 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-lisp-impact-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"RLOC" is spelled out on second use, but not on first use.

"Addresses are semantically separated in two:" was a bit rough for me.
Perhaps something like "Addresses have two components with different
semantic meanings:"?

In this text:

   Middle boxes/filters:  because of encapsulation, the middle boxes may
         not understand the traffic, which can cause a firewall to drop
         legitimate packets.  In addition, LISP allows triangular or
         even rectangular routing, so it is difficult to maintain a
         correct state even if the middle box understands LISP.
         Finally, filtering may also have problems because they may
         think only one host is generating the traffic (the ITR), as
         long as it is not de-encapsulated.  To deal with LISP
         encapsulation, LISP aware firewalls that inspect inner LISP
         packets are proposed [lispfirewall].

I wonder if we're far enough along with RFC 7258/BCP 188 that we expect
middleboxes may not understand traffic, whether it's encapsulated or not,
because of encryption. Perhaps that's worth a thought, if not a mention.

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Oct 2015 11:21:17 +0200

Hi Spencer,

> On 21 Oct 2015, at 18:42, Spencer Dawkins <[email-masked]> wrote:
> 

[snip]

Thanks for pointing this out. We have to fix this and a few other acronyms that we use first and define later.

> semantic meanings:”?

I fear it could be misinterpreted. Is not the address that has two “components”, is the addressing space that is split in two semantically different sub spaces.

What is we out the following text:

	“Addresses are separated in two sets that have different semantics meanings”

Would that work?

> because of encryption. Perhaps that's worth a thought, if not a mention.

May be modifying the first sentence as follows:

 Middle boxes/filters:  because of encapsulation or encryption, the middle boxes may
        not understand the traffic, which can cause them to drop
        legitimate packets ([RFC7258]).

Would that work?

thanks

ciao

Luigi

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 22 Oct 2015 07:11:27 -0500

Hi, Luigi,

On Thu, Oct 22, 2015 at 4:21 AM, Luigi Iannone <[email-masked]> wrote:

> I fear it could be misinterpreted. Is not the address that has two
> “components”, is the addressing space that is split in two semantically
> different sub spaces.
>

Ah, I see - you weren't making the point I thought you were making. Your
explanation was actually better than your proposed text, because it said
"address SPACE", not just addresses. Perhaps "The address space is divided
into two sets that have different semantic meanings"?

>         legitimate packets ([RFC7258]).

One of the nice security ADs may have a better read on this, but I'm
thinking the point of citing RFC 7258 is that middleboxes being clueless
will be increasingly common. Perhaps

 Middle boxes/filters:  because of increasingly common encryption as a
response to pervasive monitoring ([RFC7258]), middle boxes are increasingly
likely to be unable to understand encapsulated traffic, which can cause
them to drop legitimate packets.

Does that make sense?

Thanks,

Spencer

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Oct 2015 14:18:15 +0200

Hi Spencer,

> On 22 Oct 2015, at 14:11, Spencer Dawkins at IETF <[email-masked]> wrote:
> 

[snip]

> Ah, I see - you weren't making the point I thought you were making. Your explanation was actually better than your proposed text, because it said "address SPACE", not just addresses. Perhaps "The address space is divided into two sets that have different semantic meanings"?
>  

Looks pretty good to me. Thanks.

[snip]
> One of the nice security ADs may have a better read on this, but I'm thinking the point of citing RFC 7258 is that middleboxes being clueless will be increasingly common. Perhaps
> 
>  Middle boxes/filters:  because of increasingly common encryption as a response to pervasive monitoring ([RFC7258]), middle boxes are increasingly likely to be unable to understand encapsulated traffic, which can cause them to drop legitimate packets.
> 

Looks awesome to me. I’ll this text.
If any security ADs has further comments they are always welcome

ciao

L.