Subject: Re: [IPsec] a new IKEv2 labeled security draft is published

From: "David P. Quigley" <[email-masked]>
Date: Mon, 02 Aug 2010 08:18:08 -0400

On Fri, 2010-07-30 at 16:49 -0400, Paul Moore wrote:
> On Wed, 2010-07-28 at 00:30 -0700, [email-masked] wrote:
> > A new 00 version of IKEv2 extension for security label has just been 
> > published:
> > 
> > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00
> > 
> > Authors welcome comments from IPsec community.
> 
> Having just read the draft I think it is a bit difficult to perform any
> in-depth review without the LFS document (which is described as a work
> in progress); there just isn't any real substance in this draft in my
> opinion.
> 

What sort of substance are you looking for? The whole point of the LFS
document was that we could abstract the actual semantics and format of
labeling away and focus on the actual protocol instead. The Labeled
IPSec document should be able to be looked at without having to do so in
the context of a specific label type.

Dave

---

From: Paul Moore <[email-masked]>
Date: Mon, 02 Aug 2010 09:36:08 -0400

> the context of a specific label type.

Basically I'm looking for the kind of substance that one could use to
implement the protocol; reading this draft I just don't have that
information.  Perhaps the best example is in section 4.1, "Attribute
Negotiation"; there is only some very vague text about failing
negotiations if the label format is unrecognized, no concrete details
about how to deal with recognized label formats with invalid and/or
unauthorized labels.  I could go on, but hopefully this is enough to
demonstrate my point.

-- 
paul moore
linux @ hp

---

From: "David P. Quigley" <[email-masked]>
Date: Mon, 02 Aug 2010 09:37:28 -0400

> unauthorized labels.  I could go on, but hopefully this is enough to

The point of bringing this to the list for discussion is for issue like
this to come to the surface so I would ask that you give an extensive
list of comments. Handling unauthorized labels has nothing to do with
the LFS work so it is definitely something worth bringing to light. Now
the question is that kind of information would be something
traditionally given in the Security Architecture document. When I was
talking with Paul Hoffman about the Labeled IPSec document he said that
we should remove information that is traditionally associated with the
SA document as his assertion was if you're using security labels you
already know how to use them. He was of the belief that this document
should just be the protocol information and security labels and their
usage are not important for this document.

Dave

---

From: Paul Moore <[email-masked]>
Date: Mon, 02 Aug 2010 10:12:24 -0400

On Mon, 2010-08-02 at 09:37 -0400, David P. Quigley wrote:
> the LFS work so it is definitely something worth bringing to light.

I only mentioned your LFS draft because it was referenced a few times in
the IKEv2 security label draft and without a copy of the LFS draft it
was difficult to determine if it had any additional detail that might
help in reviewing the IKE draft.

I would encourage you to publish the LFS draft as soon as possible so
that we can take a look at both specifications together since the IKE
draft does have some reliance on the LFS draft.

> Now the question is that kind of information would be something

While leaving large chunks of the protocol out of the specification
definitely makes it easier to draft (and review for that matter), it
makes me very nervous when people start implementing the specification
later down the line as the assumptions you make when developing
implementation "A" might not work well with the assumptions I make with
developing implementation "B".  For something as critical as a security
label protocol, this could have very serious repercussions for users.

Granted, it is probably foolish (and perhaps not very desirable either)
to ask for a specification that completely removes all ambiguity, but I
think the IKE security label draft as currently written is far too vague
to be useful.  Look at the CALIPSO RFC or even the other IPsec/IKE RFCs
to see the level of specification detail that, in my opinion, should be
present in an IETF RFC.

-- 
paul moore
linux @ hp

---

From: "David P. Quigley" <[email-masked]>
Date: Mon, 02 Aug 2010 10:32:29 -0400

> draft does have some reliance on the LFS draft.

That's a good idea. I just published the document. You can find it at
the link below[1]. I also posted an email about it to the SAAG so
hopefully there will be some review from there as well.

[1]http://www.ietf.org/id/draft-quigley-label-format-registry-00.txt

> to see the level of specification detail that, in my opinion, should be

We are accepting text for the document so if there is something you
believe that should be in it such as handling unauthorized labels feel
free to write up some text and send it our way.

Dave

---

From: Paul Moore <[email-masked]>
Date: Mon, 02 Aug 2010 11:24:16 -0400

> [1]http://www.ietf.org/id/draft-quigley-label-format-registry-00.txt

Thank you.

> free to write up some text and send it our way.

Perhaps it would be better for you to document how you would assume the
implementation to work with a level of detail similar to the other IKE
and CALIPSO RFCs and then we can have another attempt at review?  I'm
saying this not to be difficult, but rather because I feel that
providing the amount of additional text that I feel is needed would be
roughly the same as writing a draft in the first place.  To be honest, I
look at this draft as an abstract for labeled IKE specification, not a
draft specification itself.

-- 
paul moore
linux @ hp

---

From: Jarrett Lu <[email-masked]>
Date: Mon, 02 Aug 2010 09:09:33 -0700

> draft specification itself.

I suppose we can add more details / text on label validations and error
handling to avoid implementation ambiguities as much as possible. Our
intent is to add the label negotiation as a simple extension to IKEv2. It
really should be a short document.

Thanks.

Jarrett

---

From: Paul Moore <[email-masked]>
Date: Mon, 02 Aug 2010 13:36:08 -0400

> really should be a short document.

Thanks, I think that should help.

-- 
paul moore
linux @ hp