Subject: Gen-ART Review for draft-ietf-lisp-crypto-09

From: Pete Resnick <[email-masked]>
Date: Wed, 12 Oct 2016 18:57:32 -0700

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Document: draft-ietf-lisp-crypto-09
Reviewer: Pete Resnick
Review Date: 2016-10-12
IETF LC End Date: 2016-10-04
IESG Telechat date: 2016-10-13

Summary: This draft is ready for publication as an Experimental RFC

Though this is not an area of expertise for me, the document is clearly 
written, I reviewed the data structures and they appear correct, and the 
document seems ready to go forward. (I do find it dicey that this is an 
Experimental document. I understand there is history here, but this is a 
full-fledged protocol document and the fact that it is only required to 
be subjected to a cursory review for Experimental status and can pass 
IESG review with one "YES" and everyone else "ABSTAIN"ing seems kinda 
ridiculous. But that's not a reason to stop this document.)

Major issues:

None

Minor issues:

None

Nits/editorial comments:

Section 9, second to last paragraph: "Otherwise, the packet has been 
tampered with and is discarded." The "tampered with" is probably 
overstating the case. I would simply say "invalid".

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Manish Kumar <[email-masked]>
Date: Thu, 13 Oct 2016 19:00:48 +0530

I guess I did mention this before but just in case that was missed - the idea of a separate confidentiality mechanism for each encapsulation/overlay protocol when these are all IP based does seem a bit inapposite to me. At a minimum, it opens up scope for additional security holes to prey upon (as against using a standard mechanism like IPsec).

Thanks,
Manish

> On 13-Oct-2016, at 7:27 AM, Pete Resnick <[email-masked]> wrote:
> 
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Though this is not an area of expertise for me, the document is clearly written, I reviewed the data structures and they appear correct, and the document seems ready to go forward. (I do find it dicey that this is an Experimental document. I understand there is history here, but this is a full-fledged protocol document and the fact that it is only required to be subjected to a cursory review for Experimental status and can pass IESG review with one "YES" and everyone else "ABSTAIN"ing seems kinda ridiculous. But that's not a reason to stop this document.)
> 
> Major issues:
> 
> None
> 
> Minor issues:
> 
> None
> 
> Nits/editorial comments:
> 
> Section 9, second to last paragraph: "Otherwise, the packet has been tampered with and is discarded." The "tampered with" is probably overstating the case. I would simply say "invalid".
> 
> -- 
> Pete Resnick http://www.qualcomm.com/~presnick/ <http://www.qualcomm.com/%7Epresnick/>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 13 Oct 2016 21:21:23 +0200

On Thu, Oct 13, 2016 at 3:30 PM, Manish Kumar <[email-masked]> wrote:
> I guess I did mention this before but just in case that was missed - the
> idea of a separate confidentiality mechanism for each encapsulation/overlay
> protocol when these are all IP based does seem a bit inapposite to me. At a
> minimum, it opens up scope for additional security holes to prey upon (as
> against using a standard mechanism like IPsec).
<snip>

I was going to respond to the original question but somehow it got lost...

The idea went through alot of discussion with different security guys to make
sure it would be as good as it could be, if I remember correctly we did all that
before it was requested to be a LISP-wg document..

I would suggest you read the introduction part again, are a few things
there that
made IPSec or any form of outer encryption out of scope. Not to forget that if
using IPSec we would have to encapsulate an already encapsulated packet...

Some other background on the document - I had two ideas, one was that we
should encrypt the xTR - xTR traffic to make it a bit more secure over whatever
medium it was crossing - and an idea that as a LISP site I should somehow be
able to signal alongside my EID that i only wanted encrypted traffic
to arrive at
my xTR's, or that I only supported a few given encryption scheme.
This and some ideas Dino already combined with other input morphed into
the document we are discussing now.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Oct 2016 03:43:43 -0700

Manish, we wanted a more integrated solution. Many products can’t do encapsulation and encryption at one time in one router. There are 2-box solutions are there. Plus, there are more RTT packet exchanges for IPsec which would cause more packet loss when the ITR would have to resolve an EID to an RLOC and do key exchange. We did this all together in one RTT so we have efficiency and integration.

Plus, we can do rekeying more efficiently and quicker. And we don’t have to store keys and have a PKI.

Dino

> On Oct 13, 2016, at 12:21 PM, Roger Jørgensen <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Oct 2016 06:15:44 -0700

> Summary: This draft is ready for publication as an Experimental RFC

Thanks for your review Pete. Brian and I appreciate it.

> Though this is not an area of expertise for me, the document is clearly written, I reviewed the data structures and they appear correct, and the document seems ready to go forward. (I do find it dicey that this is an Experimental document. I understand there is history here, but this is

The reason the document is Experimental is to be consistent with the rest of the LISP RFC set. We do have in the LISP WG charter to standards track the RFC-set and anticipate that this RFC will follow the same path. But of course, it is for the working group to decide.

> a full-fledged protocol document and the fact that it is only required to be subjected to a cursory review for Experimental status and can pass IESG review with one "YES" and everyone else "ABSTAIN"ing seems kinda ridiculous. But that's not a reason to stop this document.)

I’ll yield to others to comment on this.

> Nits/editorial comments:
> 
> Section 9, second to last paragraph: "Otherwise, the packet has been tampered with and is discarded." The "tampered with" is probably overstating the case. I would simply say "invalid”.

Fixed.

Thanks again,
Dino