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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Luigi,

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

> Hi Spencer,
>
>
> > On 21 Oct 2015, at 18:42, Spencer Dawkins <[e-mail]>
> wrote:
> >
>
> [snip]
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > "RLOC" is spelled out on second use, but not on first use.
> >
>
> Thanks for pointing this out. We have to fix this and a few other acronyms
> that we use first and define later.
>
>
> > "Addresses are semantically separated in two:" was a bit rough for me.
> > Perhaps something like "Addresses have two components with different
> > 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?
>

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"?


> >
>
> > 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.
> >
>
> 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?


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


> thanks
>
> ciao
>
> Luigi
>
>