On Mon, 2010-08-02 at 10:12 -0400, Paul Moore wrote: > On Mon, 2010-08-02 at 09:37 -0400, David P. Quigley wrote: > > On Mon, 2010-08-02 at 09:36 -0400, Paul Moore wrote: > > > On Mon, 2010-08-02 at 08:18 -0400, David P. Quigley wrote: > > > > On Fri, 2010-07-30 at 16:49 -0400, Paul Moore wrote: > > > > > On Wed, 2010-07-28 at 00:30 -0700, jarrett...@oracle.com 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. > > > > > > 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. > > > > 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. > > 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. >
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 > > 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. > > 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. > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
