Subject: [anonsec] BYPASS OR PROTECT

From: kent at bbn.com (Stephen Kent)
Date: Mon, 2 Apr 2007 14:43:45 -0400

Nico,

The existing 4301 model describes BYPASS and PROTECT as mutually 
exclusive descriptions. So, the new option, which might more properly 
be named "PROTECT IF POSSIBLE" is a third option that the user has to 
see as a distinct choice.  So long as we represent this as a new 
option (which I think may be better reinforced by the name I 
suggested above), I don't think it undermines the 4301 model.

Of course we still have to make sure that there is no overlap (in 
terms of address space or name space)  between entries in the SPD 
that are described as PROTECT and ones that are labeled as "PROTECT 
IF POSSIBLE." The same is true for the PAD. These constrains are 
needed to satisfy the "don't undermine the existing 4301 access 
control model" criteria we discussed in Prague.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 3 Apr 2007 01:38:34 -0500

> suggested above), I don't think it undermines the 4301 model.

Thank you.  I agree, PROTECT IF POSSIBLE is a better name.

> control model" criteria we discussed in Prague.

I agree, but this needs a bit of refinement.  The point is that such
overlap does not happen accidentally.

First, administrators who want to write simple rules might appreciate a
way to write few PROTECT or DISCARD rules that cover most traffic and
PROTECT IF POSSIBLE that "punch holes" into the former for specific
IPsec-aware applications.

Second, IPsec-aware apps should not be able to create PROTECT IF
POSSIBLE rules that punch holes in system policy that would PROTECT/
DISCARD the apps' traffic unless the apps are sufficiently privileged.
OTOH, IPsec-aware apps should be able to PROTECT or PROTECT IF POSSIBLE
traffic that would otherwise be BYPASSED.  (This is the rule implemented
in Solaris, BTW.)

Nico
--

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 03 Apr 2007 12:29:34 -0400

Nicolas Williams wrote:
> You may also recall that in the case of the core BTNS document the
> access control issue had been about ensuring that BTNS peers not be
> allowed to assert traffic selectors that non-BTNS peers are allowed to
> assert.  And recall that we addressed this by providing that the PAD be
> searched twice, once at authentication time and once at CHILD SA
> creation time, the latter to find that the asserted traffic selectors do
> not overlap with ones reserved for non-BTNS peers.

   I want to say that Openswan does precisely this when it implements
Opportunistic Encryption a la RFC4322.

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 03 Apr 2007 12:31:27 -0400

> be named "PROTECT IF POSSIBLE" is a third option that the user has to 

   As this is used primarily on the responder, I suggest th wording be infact:
     "PROTECT IF REQUESTED"

> IF POSSIBLE." The same is true for the PAD. These constrains are 

   This is a general  problem in the PAD, and
SPD with overlapping items. i.e. this problem already exists, and has been solved.

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 4 Apr 2007 11:17:57 -0400

>traffic that would otherwise be BYPASSED.  (This is the rule implemented

Good points.  I think this says we may need another SPD extension, 
one that marks rules as ones that are inviolable, vs. ones that may 
be overridden by a user/app as you described above.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 4 Apr 2007 11:22:04 -0400

>    As this is used primarily on the responder, I suggest th wording be infact:

Does the spec say that it is used ONLY by a responder? If so, then 
your wording sounds better. If not, ...

>SPD with overlapping items. i.e. this problem already exists, and 

I'm not quite sure what you mean above. The ordering of the PAD and 
SPD allows one to have overlapping entries, but those were entries 
that all had the same precedence, and which offer a binary choice. 
The notion of PROTECT IF REQUESTED/POSSIBLE is a new concept with 
different semantics and that's why I believe we have to be more 
sophisticated in how we add this feature to the PAD and SPD.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 4 Apr 2007 10:47:59 -0500

> be overridden by a user/app as you described above.

Another way to look at it is to have system policy determine insertion
points into the SPD for app-requested rules -- since the SPD is ordered
then the insertion points determine what rules the apps can "punch
holes" into.  There could be multiple such insertion points,
corresponding to multiple local privilege levels.

So the SPD extension, then, would be a rule type that declares an
insertion point for specific applications or local privileges.

Since there's more than one way to represent this we need English-
language text and a canonical representation that implementors can
ignore, provided that they provide equivalent functionality.

Personally I prefer the insertion point approach since it does not
require modifying existing rules.  Your notion of "inviolable" rules
maps into placing such rules ahead of any insertion points.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 4 Apr 2007 12:06:22 -0400

At 11:50 AM -0400 4/4/07, Dan McDonald wrote:
>For example, OpenSolaris has "inviolable" as a global flag (which is disabled
>by default) for the entire SPD.  The only exception to sockets overriding the
>SPD is for a socket that wishes to PASS - the process that wishes to PASS
>MUST be privileged AND the "inviolable" flag MUST be disabled.
>
>Having per-rule inviolability is a good idea, but we need to consider apps
>AND their privileges.  For another example, I really want my IKE daemon to
>speak in the clear REGARDLESS of the contents of the SPD.
>
>Dan

Dan,

I think the WG has to discuss just what semantics we need for the 
flag, but it's good to know that some implementations have analogous 
capabilities now.

I'm pretty sure 4301 says that IKE messages cross the IPsec boundary 
and that there need to be SPD entries to enable this, so your last 
comment above is in conflict with that.

Steve

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Wed, 04 Apr 2007 13:09:51 -0400

>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:
    Stephen> At 12:31 PM -0400 4/3/07, Michael Richardson wrote:
    >>> exclusive descriptions. So, the new option, which might more
    >>> properly be named "PROTECT IF POSSIBLE" is a third option that
    >>> the user has to
    >> As this is used primarily on the responder, I suggest th wording
    >> be infact: "PROTECT IF REQUESTED"

    Stephen> Does the spec say that it is used ONLY by a responder? If
    Stephen> so, then your wording sounds better. If not, ...

  1) BTNS says nothing about how nodes know to do BTNS. We explicitely
     left out discovery.
     So, an initiator would have to some some PAD/SPD entry that told it
     to do something.
     
     If that thing was "PROTECT IF REQUESTED", and the application
     requested protection, then that wording would fit.

  2) I think that it does make most sense to have such entries on the
     responder. I expect to see more clear "PROTECT" entries on the
     "clients" (I use that label vs initiator, on purpose)

    >>> Of course we still have to make sure that there is no overlap
    >>> (in terms of address space or name space) between entries in the
    >>> SPD that are described as PROTECT and ones that are labeled as
    >>> "PROTECT IF POSSIBLE." The same is true for the PAD. These
    >>> constrains are
    >> This is a general problem in the PAD, and SPD with overlapping
    >> items. i.e. this problem already exists, and has been solved.

    Stephen> I'm not quite sure what you mean above. The ordering of the
    Stephen> PAD and SPD allows one to have overlapping entries, but
    Stephen> those were entries that all had the same precedence, and
    Stephen> which offer a binary choice. The notion of PROTECT IF
    Stephen> REQUESTED/POSSIBLE is a new concept with different
    Stephen> semantics and that's why I believe we have to be more
    Stephen> sophisticated in how we add this feature to the PAD and
    Stephen> SPD.

  Can you give me an example of an ordered PAD that would still be
ambiguous?
  Your word "precedence" is funny to me, since the entries don't have
the same precedence if they are ordered.

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 4 Apr 2007 12:27:30 -0500

> the same precedence if they are ordered.

I too wondered about the "but those were entries that all had the same
precedence" bit -- these are ordered lists, so no two rules can have the
"sam precedence."

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 4 Apr 2007 14:08:18 -0500

>    As this is used primarily on the responder, I suggest th wording be infact:

Actually, these rules might not be used at all by administrators, but be
created dynamically by applications.  In any case, they are used on both
sides (client and server).

We could just call them TEMPLATE BYPASS OR PROTECT (yes, I still like
the name I picked originally) -- something that indicates: a) the fact
these aren't rules as such but rules that give rise to flow-specific
rules, and b) that the latter may be either BYPASS or PROTECT rules.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 5 Apr 2007 07:18:07 -0400

>corresponding to multiple local privilege levels.

one could do that, although I worry that this sounds fairly complex, 
especially because it sounds like changes in SPD affect where 
different rules apply.

>insertion point for specific applications or local privileges.

how would one define the insertion point in a way that doesn't get too complex?

>ignore, provided that they provide equivalent functionality.

agreed.

>maps into placing such rules ahead of any insertion points.

I see what you mean, and I appreciate the generality, but I do worry 
about creating a sophisticated access control capability that will 
induce management errors.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 5 Apr 2007 07:32:37 -0400

At 12:27 PM -0500 4/4/07, Nicolas Williams wrote:
>_______________________________________________

The issue is not precedence once the list (PAD or SPD) is ordered. 
The issue is that given an extant, presumably OK list, if someone 
tries to add a new entry at a given location in the ordered database, 
are they allowed to do so. If PAD/SPD entries have a label that 
indicates the precedence/priority of the each entry, analogous to 
user/supervisor state, then maybe one can decide whether the new 
entry can be added (at the requested point) based o the comparison 
with the extant entries and their labels.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 5 Apr 2007 08:10:09 -0400

At 1:09 PM -0400 4/4/07, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

I was focusing on the requester being the peer, not the application 
triggering SA creation.

I am still a bit confused. Are you saying that if an app requests 
IPsec protection for a connection then this entry will try to create 
an SA, but it will not try to create an SA if the app does not 
request it? I guess I tend to think in PAD/SPD -centric terms, not 
app-centric terms, which would say create the SA IF possible, 
irrespective of whether an app requests it or not.

I also see a possible disconnect here. Consider an SPD entry that 
supports our new "PROTECT IF X" feature and that entry is a tunnel 
for ALL TCP traffic between Host A and Host B. Let's say that one app 
does not request an SA between A and B, and so an unprotected TCP 
connection is established. Then a second app requests an SA, if 
possible. Do we create a tunnel and migrate the old, unprotected 
traffic to the tunnel? If not, we would seem to have a conflict 
between two SAD entries, one labelled BYPASS and one ESP, with the 
same scope (based on the SPD entry I described above). have we 
discussed this scenario before, and if so, what was the conclusion?

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 5 Apr 2007 08:13:03 -0400

>rules, and b) that the latter may be either BYPASS or PROTECT rules.

I'n not saying this is a bad idea, but I don't think I've seen a 
clear description of how the templates fit into the extant 4301 
model. maybe we need more details.  Also, if apps create the rules, 
there is still a need to be able to determine if they conflict with 
other rules already created by an admin, in order to be sure that an 
admin-controlled access control policy is not subverted.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 5 Apr 2007 10:41:43 -0500

> especially because it sounds like changes in SPD affect where 

That's the nature of policies consisting of ordered rulesets.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 5 Apr 2007 10:46:49 -0500

> how would one define the insertion point in a way that doesn't get too 

You put that "inviolable" rules that you posited ahead of the insertion
point.  All others go behind.  For a simple system with two levels of
privilege (w.r.t. IPsec policy), privileged and unprivileged, you need
two insertion points: one at the head of the SPD-S for privileged apps
to request BYPASS in contravention to system poilicy, and one at the end
of the SPD-S for unprivileged apps to request PROTECT where system
policy would BYPASS.  (Yes, I ignored DISCARD rules there.).

> induce management errors.

Me too.  But how can we ignore the "where" in the SPD to insert
API-driven rules?  Do you believe that your "inviolable" flag would
allow us to ignore SPD order for such rules?

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 5 Apr 2007 10:49:47 -0500

> with the extant entries and their labels.

This sounds very much like what I meant by insertion points -- you have
to know, or else you have to have some way to figure out where in the
SPD to insert API-driven rules.

(Of course, native implementions might not implement API-driven rules as
rules that are inserted into the SPD as there are other morally
equivalent ways to describe this, but we're trying to stay close to the
RFC4301 model.)

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 5 Apr 2007 17:52:32 -0400

At 8:49 AM -0400 4/5/07, Dan McDonald wrote:
>On Thu, Apr 05, 2007 at 08:10:09AM -0400, Stephen Kent wrote:
>
><SNIP!>
>
>Connection latching covers this.  The first TCP connection between A and B
>will latch into BYPASS, and the second one will latch into ESP.  Once a
>connection is latched, policy changes will not affect the connection.
>
>Dan

I don't see how this is consistent with the 4301 model of caching SPD entries.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 5 Apr 2007 17:48:43 -0500

> >>  for ALL TCP traffic between Host A and Host B. Let's say that one app

PROTECT OR BYPASS is intended to support application use of IPsec and
very much relates to specific traffic flows -- all SPD entries resulting
from template PROTECT OR BYPASS entries will be for specific 5-tuples
(yes, SCTP's multi-homing angle should be addressed).

> I don't see how this is consistent with the 4301 model of caching SPD entries.

Which part isn't consistent?  Keep in mind that each latch is for a
specific packet flow.

Are you concerned about tunnels and connection latching?

Let's imagine a scenario where client A and server S are trying to
communicate using PROTECTed traffic but A has to tunnel through an SG,
G, and has to PROTECT all traffic between A and the SG.  This means we
have to nest IPsec.  In the following lame ASCII-art the thick line
represents the tunnel between A and G, and the thin line represents
end-to-end IPsec between A and B:

         A                        G
          /----------------------\
   app <--+----------------------+-----------------> B
          \----------------------/

Here the connection latch is between the application on A and B and
though PROTECTed it is further encapsulated into the tunnel between A
and G.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 6 Apr 2007 12:50:39 -0400

>(yes, SCTP's multi-homing angle should be addressed).

OK, then we need to make sure that this, and analogous restrictions, 
are stated explicitly.

>Which part isn't consistent?  Keep in mind that each latch is for a

If we restrict the sorts of SPD entries top which BTMS applies, then 
the problem I cited does not arise. Otherwise, we have a scenario in 
which there is an extant, BYPASS SA and a new, PROTECTED SA, and 
there is no way to decide which traffic belongs on which SA, based on 
the cached SPD entry model defined in 4301.

>end-to-end IPsec between A and B:

How one uses entries in the SPD caches and in the forwarding tables 
to create nesting of SAs is already defined in the 4301 model. That 
was not my concern.

I admit that I do not understand  how connection latching is realized 
relative to the 4301 model.  When I look at your connection latching 
I-D, I see some new terms, e.g., "template" PAD entry and "cloned" 
PAD and SPD entry, and an informal description of how to use them to 
effect connection latching.  I didn't see a description of how the 
4301 model is extended to accommodate these new features. I think 
that needs to be part of the document, i.e., a comparison of how 4301 
describes packet processing vs. what will now be required, and an 
analysis of why the changes do not undermine the security provided by 
4301.

Additionally, if there are any changes that affect the performance 
features of 4301, e.g., the ability to cache de-correlated SPD 
entries, that too needs to be addressed.  For example, an important 
feature of 4301 is the use of caches, to avoid the need to search the 
SPD for each outbound packet, or to search it to verify that a packet 
received on an SA was consistent with the access controls for that 
SA.  The text in the connection latching I-D does not make clear if 
the same processing model applies, given the references to cloned and 
template PAD and SPD entries

Also, whereas the BTNS I-D describes adding ONE new PAD entry, at the 
end, to allow communication with unauthenticated peers, we have been 
discussing much more elaborate capabilities, which require multiple 
new PAD entries, insertion at other than the end of the PAD table, 
restrictions on the types of SPD entries can can be safely used (as 
you explained above), etc. These are not in the BTNS I-D, and they do 
not appear to be in the connection latching I-D.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 6 Apr 2007 17:12:51 -0400

At 10:46 AM -0500 4/5/07, Nicolas Williams wrote:
>...

I had a very simple model in mind, which might be too simplistic, but 
let me state it anyway.

For what I believe is the common case of user vs. supervisor, we 
would need to mark rules as "U" or "S." When a newly proposed "U" 
rule is to be inserted, we invoke an algorithmic check to determine 
whether it would affect any "S" rule. If so, then  the attempt to 
insert the "U" rule is rejected. In this model one does not need to 
define points where "U" rules could be inserted.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 6 Apr 2007 17:14:42 -0400

>That's the nature of policies consisting of ordered rulesets.

This is not true for many access control models. We adopted the 
ordered rule model because it was commonly employed in other 
contexts, e.g., firewall filter rule, and because, with caching, it 
works very well at layer 3.

Also, recall that the 4301 processing model uses caches and that 
calls for the SPD to be de-correlated, which implies no ordering. So, 
although it still makes sense to offer an interface for an ordered 
SPD to a human user to administer, if we talk about making changes to 
an SPD dynamically, from an app, we are assuming that the correlated 
SPD is used as the reference, and then we have to de-correlate it, 
see what impact that has on extant SPD cache and SAD entries, etc.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 6 Apr 2007 16:19:52 -0500

> define points where "U" rules could be inserted.

Marking an insertion point into the SPD -- bissecting it -- is the
equivalent of what you propose: all the rules ahead of the insertion
point for unprivileged apps are 'S' and all the rules behind it are 'U'.

We need a canonical model only to explain what the correct semantics
are, not to dictate implementation.

I fully expect that some implementations will do something really
simple, like: unprivileged app-driven PROTECT rules go at the back of
the SPD, while privileged app-drive BYPASS rules go at the head of the
SPD.  I expect such an implementation to match the semantics of that
we'll describe for PROTECT OR BYPASS (and not because we should describe
what implementations that have this feature do, but because this is
fairly natural).

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 6 Apr 2007 16:23:34 -0500

> calls for the SPD to be de-correlated, which implies no ordering. So, 

However, the access control semantics of RFC4301 depend on the SPD being
ordered, and SPD de-correlation is intended to preserve the access
control semantics of a pre-de-correlation, ordered SPD.  N'est ce pas?

> see what impact that has on extant SPD cache and SAD entries, etc.

My view was that app-driven rules, in the model we'll describe, are
inserted into a normal SPD and then de-correlation is done again in
order to install the new SPD.

Implementors may choose to do this differently, provided that they
maintain the same semantics.

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 9 Apr 2007 08:28:35 -0400

>control semantics of a pre-de-correlation, ordered SPD.  N'est ce pas?

right.

>order to install the new SPD.

OK, then let's say so explicitly in our description of the nominal model.

>maintain the same semantics.

right, but we need a precise nominal model, like 4301, to provide a 
testable reference.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 9 Apr 2007 08:27:01 -0400

>point for unprivileged apps are 'S' and all the rules behind it are 'U'.

You seem to be assuming that we perform a sort on the (correlated) 
SPD to put all S rules above all U rules. If no U rules are allowed 
to overlap with any S rules, then that should allow the simple, 
two-tier SPD that you are suggesting. I don't recall you explicitly 
stating that assumption in prior messages, or maybe I just missed it. 
Yes, I thin this would work.

agreed.

>what implementations that have this feature do, but because this is

Do we agree that the spec needs to have one model that has enough 
detail to be unambiguous and testable, like 4301, but also need to 
tell implementers that they are free to implement the model in nay 
way that exactly matches the model's external behavior?

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 9 Apr 2007 10:12:46 -0500

> right, but we need a precise nominal model, like 4301, to provide a 

The next revision of the connection latching I-D will say so, or perhaps
this should be a separate I-D (Sam seemed to think so).

What's the status of the core I-D?

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 9 Apr 2007 10:36:14 -0500

> stating that assumption in prior messages, or maybe I just missed it. 

Indeed, that's my assumption, and I state it explicitly in this thread,
but not in the I-D.

> Yes, I thin this would work.

Me too :)

> way that exactly matches the model's external behavior?

Yes, you and I do, and I suspect that the rest of the WG will agree as
well.

Now I have to go re-read what RFC4301 has to say about the SPD...  In
this thread we've not taken into account RFC4301's logical split of the
SPD into three pieces (SPD-S, -I and -O).  I'm sure that won't be a
problem.

Nico
--

---

From: julien.IETF at laposte.net (Julien Laganier)
Date: Wed, 11 Apr 2007 11:01:25 +0200

On Monday 09 April 2007 17:12, Nicolas Williams wrote:
> > >My view was that app-driven rules, in the model
> > > we'll describe, are inserted into a normal SPD
> > > and then de-correlation is done again in order
> > > to install the new SPD.
> >
> > >Implementors may choose to do this differently,
> > > provided that they maintain the same semantics.
> >
> > right, but we need a precise nominal model, like
> > 4301, to provide a testable reference.
>
> The next revision of the connection latching I-D
> will say so, or perhaps this should be a separate
> I-D (Sam seemed to think so).
>

Nico, the WGLC concluded on 2007-04-09, hence I thought 
the WG would request publication of the core I-D to 
IESG.

Does the discussion you and Steve have had so far 
impact that? In other words, should we delay 
submission of the core I-D to IESG?

-- julien / BTNS co-chair

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 13 Apr 2007 11:15:35 -0500

> the WG would request publication of the core I-D to 

OK.

> impact that?

No, it does not.

>              In other words, should we delay 

Nope.  I think it's ready.

Nico
--

---

From: julien.IETF at laposte.net (Julien Laganier)
Date: Mon, 16 Apr 2007 13:22:10 +0200

On Friday 13 April 2007 18:15, Nicolas Williams wrote:
> > Nico, the WGLC concluded on 2007-04-09, hence I
> > thought the WG would request publication of the
> > core I-D to IESG.
>
> OK.
>

Before I forward it to IESG, I need you to resubmit a 
new version of the draft that passes all IDnits 
checks:

<http://tools.ietf.org/tools/idnits/>

It currently has 4 errors:

- No 'Intended status' indicated

==> Use "std" as category in the XML's <rfc> mark (e.g. 
<rfc category="std" ipr="full3978" > )

- Lack an IANA Considerations section

==> If the document hasn't IANA considerations, include 
an IANA cons section stating "This document has no 
IANA considerations"

- Bad Normative/Informative ref split causing downrefs.

==> I think [I-D.ietf-btns-connection-latching], 
[I-D.ietf-btns-prob-and-applic], 
[I-D.ietf-kitten-gssapi-channel-bindings], and 
[I-D.ietf-nfsv4-channel-bindings] are Informative 
rather than Normative...

- Normative reference to obsolete RFCs (RFC 2408 and 
RFC2409)

==> Suggest removing them, or move to Informative?

Once those are taken care of, I'll forward the draft to 
IESG.

--julien / BTNS co-chair.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 16 Apr 2007 10:40:08 -0500

OK.

OK.

> [I-D.ietf-nfsv4-channel-bindings] are Informative 

And I-D.ietf-nfsv4-channel-bindings has been replaced with
I-D.williams-on-channel-bindings.

OK.

> ==> Suggest removing them, or move to Informative?

Those should be informative, since they are only referenced in the
Introduction.  Similarly for RFC4306 (IKEv2).  The only normative
references left are to RFC2119 and RFC4301.

> Once those are taken care of, I'll forward the draft to 

I'll re-submit shortly.

Nico
--