Subject: [anonsec] [IESG Secretary] Evaluation: draft-bellovin-useipsec-04.txt to BCP

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Tue, 20 Sep 2005 15:13:24 -0400

An embedded message was scrubbed...
From: IESG Secretary <iesg-secretary at ietf.org>
Subject: Evaluation: draft-bellovin-useipsec-04.txt to BCP 
Date: Tue, 20 Sep 2005 11:45:56 -0400
Size: 5398
Url: http://www.postel.org/pipermail/anonsec/attachments/20050920/970e0efd/attachment.mht

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Thu, 22 Sep 2005 10:36:40 +0200

Sam, below,

On Sep 20, 2005, at 21:13, Sam Hartman wrote:
> I don't know whether the following document was ever last called.
> however people in the BTNS working group may want to review it and see
> whether its advice is in alignment with the direction we are going.
>
> Please let me know by the end of the week this week if there are any
> significant blocking issues.

> http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt

I briefly re-reviewed the document (I had read an earlier version of  
it),
and I didn't see substantial issues.  AFAICT, BTNS work is not likely
to change the situation as described in Sections 3.4, 5, or 6 any  
soon, even
though I of course hope that we will eventually be able to change it.

Hence, my only comment is that the document is very much looking at
the currently deployed situation, and at protocols that must work with
what is out there now and can't require anything more.  For protocols
that would require changes to the kernel anyway, there might be a  
slightly
wider set of options available, since it might be reasonable to expect
small changes (such as better API) to the local IPsec implementation,  
too.

So, maybe a note stating that the document describes the situation as
out there now, and that while there are likely to be other options
in the future, people are not recommended to keep their breath unless
they plan to do substantial changes to the IP, or transport, or API
part of the stack?

Leaving BTNS behind, I didn't see the document to discuss mobility at
difficulties related to that at all.  But maybe you have already brought
this to the attention of the MOBIKE WG?  (I am currently not following
that WG.)

--Pekka Nikander

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 23 Sep 2005 11:02:02 -0700

I posted my comments off-line, but some of them are germane to this reply...

> though I of course hope that we will eventually be able to change it.

Agreed - there's the question of whether to foreshadow or not. The doc
already refers to a number of I-Ds in other places, so it'd still be
useful and appropriate to add something. To that end, I noted 4 groups
of mods that might be useful:

BTNS-related:
1. to add a statement about BTNS at end sec 3.3 on key management and
sec 4 on IPsec availability (where keying affects availability)

i.e., the document doesn't note that key systems themselves cause IPsec
to be hard to configure, and that's a significant impediment.

Tunnel vs. transport related:
2. to add a statement about sec 3.2's tunnel vs. transport (vs.
transport on IP tunnel, as you might expect I'd notice)

The following two are just general input:

3. to clarify some statements, e.g., that "IP header" in some places is
vague (original, vs encapsulation)

4. to explain when inadequacies in IPsec implementations are due to
non-compliance vs. permitted implementation trade-offs (e.g., lack of
port selectors vs. small key tables)

Some of the personal positions made sweeping assertions about the
future, or value judgements about current systems ('mistake', 'wrong')
could also be stated more objectively and would result in a more useful
document.

> this to the attention of the MOBIKE WG?  (I am currently not following

I also wonder why it didn't appear to have been posted to the ipsec
mailing list for feedback (unless it was and I missed it - I checked the
archives and found no related post for the past year ;-)

Joe