Subject: draft-touch-ipsec-vpn-06.txt

From: Ross Callon <[email-masked]>
Date: Wed, 21 Jan 2004 15:53:02 -0500

We have been notified that the IESG is considering publication 
of an individual contribution entitled: 
	Use of IPsec Transport Mode for Dynamic Routing
	draft-touch-ipsec-vpn-06.txt
	http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-06.txt

This document is related to use of IPsec for support of VPNs. From 
the abstract of the document, it states in part:

	This document addresses the use of IPsec to secure the links 
	of a virtual (private) network (VN/VPN)...

Given that the document overlaps with our work, the issue has come
up regarding whether the document should be published without any
working group consideration, or whether the author should be requested
to bring the work to the l3vpn working group for consideration. 

This leads to two questions:

  - Does the l3vpn working group feel that this document should be 
reviewed by a public working group, such as the l3vpn working group, 
prior to publication?

  - Do we have any technical comments on the document?

Comments to the list, please.

Thanks, Ross

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Jan 2004 13:29:28 -0800

Ross Callon wrote:

> working group consideration,

This document has been in development since 2000, and has been brought 
several times (with presentations) to both the IPsec and PPVPN WGs for 
comment and feedback, which has already been incorporated. Please check 
the list archives (notably ppvpn, since versions were posted there in 2002).

 > or whether the author should be requested

It has been, multiple times. Please review the archives for comments 
that have already been made on the precursor to this list.

Joe

---

From: Eric Rosen <[email-masked]>
Date: Thu, 22 Jan 2004 10:27:37 -0500

I think it  would be useful to  have an RFC which discusses  the issues that
arise  when you  want to  use  an IPsec  Security Association  as a  routing
adjacency. In fact, it might even be  useful to have a standard way of doing
this that would ensure multi-vendor interoperability.  

As Claudio points  out, implementors do know how to do  this, and there have
been many products on the market for years that do this.  Whether they do it
in  an  interoperable  manner  is  another question.   Whether  this  is  in
violation of the IPsec standard is a further question. 

I'd have  thought that a draft  on this topic, even  an informational draft,
would need the approval of the IPsec WG.  I am concerned about the fact that
the IPsec WG has failed to progress this draft.  

Given that there are many deployed  products that do routing over IPsec, I'd
think  an informational  draft on  the topic  would benefit  from  making it
clearer  what the existing  practices and  what the  interoperability issues
are.

With  regard  to the  draft's  relation to  L3VPN,  the  L3VPN charter  does
unfortunately include  "CE-based VPNs using IPsec".  Unless  this is removed
from the charter (which would be a good thing imho), I think it would be odd
for an individual draft on the topic to be published.

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jan 2004 09:53:07 -0800

Eric Rosen wrote:

> would need the approval of the IPsec WG. 

The IPsec WG already decided on this issue and suggested how to proceed
- in the manner we are already doing.

> I am concerned about the fact that

It was never an IPsec WG document. The time delay is largely due to
input from other WGs who 'discover' it and want to revisit issues that
have already been covered ;-)

> clearer  what the existing  practices and  what the  interoperability issues

The doc already discusses interoperability (i.e., that transport mode/IP
tunnel and tunnel mode interoperate on the wire), and lists the various
approaches in detail.

> for an individual draft on the topic to be published.

The current CE-based L3VPN docs already cite this draft, directly or
indirectly. CE-based L3VPNs are only one way our draft might be used;
there are places where dynamic routing is used independent of a CE-based
solution.

Our draft - and our work for several years - is more closely associated
with the IPsec WG due to the more direct impact on 2401bis.

Paul Knight had an earlier summary of the various techniques for doing 
tunnels and their interaction with routing - which includes refs to our 
draft - and is more closely the summary and L3VPN-focused draft that 
you're proposing. You might want to solicit that document to focus on 
L3VPN issues.

Joe

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 10:36:00 -0800

Joe,

I always liked the idea of using a IP-IP tunnel interface and securing with IPsec transport mode SA, but
i am not sure i understand/agree with the issues regarding the alternative proposal mentioned in
section 4.1.1. I am trying to understand why alternative 1 is a bad idea. There are some implementations
which do this today.

        4.1.1 Alternative 1: IPsec with Interface SAs

            In the first alternative, each IPsec tunnel mode SA is required to
            act as a full-fledged network interface. This SA interface acts as
            the outbound interface of the virtual destination's forwarding table
            entry. IPsec dynamically updates the SA interface configuration in
             response to SAD changes, e.g. caused by IKE negotiation.

Could you elaborate on what this dynamic update is ?

            This approach supports dynamic routing and existing source address
            selection rules, but requires extensions to the IPsec architecture
            that define tunnel mode SA interfaces and their associated management
            procedures.

What did you mean by "associated management procedures ? 

            It would necessitate recapitulating the definition of the entirety of
            RFC 2003 IPIP encapsulation, including the association of tunnels
            with interfaces, inside IPsec. This defeats the modular architecture
           of the Internet, and violates the specification of type 4 IP in IP
            packets as being uniquely defined by a single Internet standard (it
            is already standardized by [N4]).

For all practical purposes, it is an IP-IP interface. I see it as IPsec using
the encapsulation scheme of RFC2003 which is what tunnel mode SA
does anyway.  There is also another difference. If you use IIPtran, you have
to use the destination address to infer the VPN the packet belongs to.
This means, you have to have one address per VPN for the box. If you
support multiple VPNs, then this is a disadvantage. In the
case of modelling ipsec tunnel mode SA as an interface, you can  just use
the SPI alone (which is allocated unique for the box) for finding out the
VPN. You just need one address for the whole box which really is
a big advantage.  Is that right ?

-mohan

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jan 2004 10:55:37 -0800

> section 4.1.1. I am trying to understand why alternative 1 is a bad idea. There are some implementations

First, because 2401bis makes it hard if not impossible, given a 
centralized SAD.

> Could you elaborate on what this dynamic update is ?

IKE negotiation updates the SAD - when a new SA is negotiated, it is 
entered into the SAD and takes effect

> What did you mean by "associated management procedures ? 

See RFC2401 and the IKE RFCs.

> For all practical purposes, it is an IP-IP interface.

Except that IP-IP interfaces are routable, whereas IPsec tunnels need 
not be implemented as routable interfaces.

> I see it as IPsec using
> does anyway.

Tunnel-mode SAs aren't routable interfaces necessarily.

> There is also another difference. If you use IIPtran, you have

IIPtran uses the address to demux, not the SPI. This means that the 
virtual network is _independent_ of whether IPsec is used or not.

Dynamic routing is based on addresses; there are emerging standards for 
how to augment those addresses with IDs outside the SPI space (e.g., VPN 
IDs) which would allow reuse of addresses that touchdown at the same 
node - regardless of whether IPsec is used or not.

A L3VPN doc (such as Knight's?) would address these issues in specific, 
but our draft is intended to be more general.

Joe

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 11:20:31 -0800

> not be implemented as routable interfaces.
We are discussing about the alternative 1, where the IPsec tunnel is an interface.

> Tunnel-mode SAs aren't routable interfaces necessarily.

Again, i thought we are discussing about alternative 1.

> node - regardless of whether IPsec is used or not.
In the forwarding plane, when a packet enters IP, you still need something in
the IP header or following it, to differentiate the multiple VPNs. Are you
saying that there might be a different header with the packet  that would
allow you to differentiate the multiple VPNs ?

> but our draft is intended to be more general.

I could not locate this document anywhere. Do you have a copy of it ?

thanks
mohan

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jan 2004 11:32:33 -0800

> We are discussing about the alternative 1, where the IPsec tunnel is an interface.

Except where they are not (the "need not" part).

> Again, i thought we are discussing about alternative 1.

Again, the "necessarily" part is important.

The issue is that 2401bis would have to force an implementation, which 
neither 2401 nor 2401bis do (or should, IMO).

> allow you to differentiate the multiple VPNs ?

Either the IP address (which is what we do) or a VPN-ID in an inner 
header or option allows that. Overloading the SPI for that has numerous 
complications.

> I could not locate this document anywhere. Do you have a copy of it ?

http://www.ietf.org/internet-drafts/draft-knight-ppvpn-vr-protocol-00.txt

is related. Look for other drafts by that author.

Joe

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 12:22:46 -0800

> neither 2401 nor 2401bis do (or should, IMO).
I am a bit confused. We are comparing IIPtran with Alternative 1.
Alternative 1 needs some clarifications in rfc2401 about tunnel mode SAs
and so does IIPtran.

> header or option allows that. Overloading the SPI for that has numerous 
I don't know  what complications you refer to. Using IIPtran in this scenario
is not easy. You have to pre-setup all the IP-IP interfaces, one for each
VPN. In Alternative 1, IKE can be used to dynamically plumb these
interfaces. 

thanks
mohan

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Jan 2004 12:26:57 -0800

> Alternative 1 needs some clarifications in rfc2401 about tunnel mode SAs

Alternative 1 requires 2401bis specify an implementation, which it is 
not likely to do (and largely inappropriate as well).

IIPtran requres 2401bis permit transport mode between gateways - which 
it already does, and is a protocol specification issue.

> VPN. In Alternative 1, IKE can be used to dynamically plumb these

That's all static. The dynamic routing protocols need to be modified to 
exchange SPIs now, to resolve different VPNs that reuse addresses. The 
alternative is to use routing-specific information - IP addresses or VPN 
IDs - instead.

Joe

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Jan 2004 16:03:10 -0800

Joe,

> it already does, and is a protocol specification issue.
But section 4.2.4 points out the inter-op problem also with IIPtran which
alternative 1 does not have.

My point is alternative 1 is not inferior on technical grounds. It is as good as IIPtran.
The only problem i can see is its dependency on rfc2401. IIPtran may not have this
dependency but you can have problems negotiating a transport mode SA if the
other end thinks that it is tunnel mode.

> alternative is to use routing-specific information - IP addresses or VPN 
Why do you have to exchange SPIs ? IKE would exchange SPIs and the
ID payload would carry VPN-IDs, one per VPN. Dynamic routing protocols when
receiving packets know exactly which VR the packet belongs to (ip stack would
initialize the VR and an extra socket option to retrieve it) and hence
which FIB to associate the routes to. 

-mohan

---

From: Mark Duffy <[email-masked]>
Date: Fri, 23 Jan 2004 00:10:19 -0500

>reviewed by a public working group, such as the l3vpn working group,

I would think that should be more a matter of ietf policy regarding 
personal submission RFCs than what any wg thinks.  Unless the policy is to 
ask relevant wg's :-)

>   - Do we have any technical comments on the document?

The basic concept of forming virtual links by first applying IP-in-IP 
tunnelling, then securing them by applying transport mode IPsec to the 
resulting packets seems a good one to me.  (And it is already embodied in 
at least one document that is a product of this wg.)

As an aside, I would be quite interested for the working group to take on 
the effort to progress a *standard* for virtual links.  It should go a step 
further and provide a way to convey to the far end what vpn context a given 
tunnel is for.  Those deeply interested in this subject might want to look 
at <http://www.ietf.org/internet-drafts/draft-duffy-ppvpn-ipsec-vlink-00.txt>
which provides a survey of issues in this space and of potential solutions.

Anyway, back to draft-touch.

I think the basic approach presented is sound and appropriate.  I do think 
the message gets a little lost in all the description of other possible 
approaches  and why they don't work.  I found those descriptions difficult 
to follow.

The draft expresses an interpretation of RFC 2401 that I believe is 
excessively rigid and literal.  E.g. in concluding that transport mode may 
not be used between two gateways, and that protocol #4 encapsulations must 
be skipped past in evaluating SPD policy to look for a transport header 
deeper in the packet.

The draft on page 7 states:
   There are two common implementation scenarios for tunnel mode SAs:
    One is based on firewall-like packet matching operations where tunnel
    mode SAs are not virtual interfaces, another is tunnel-based, and
    treats a tunnel mode SA as a virtual interface. The current IPsec
    architecture does not mandate one or the other.
This is completely outside my understanding of RFC 2401.  2401 is 
completely oriented towards the policy based approach.  I am unaware that 
it provides in any way for treating a tunnel mode SA as a virtual 
interface.  In fact it does much to obstruct that viz. SPD policy and 
packet selectors.

Nit: the link numbers on figure 3 do not seem to match some references to 
them in the preceding paragraphs.

Previous revisions of this document contained the concept that if one sends 
an IKE proposal for transport mode protection for protocol #4, then one is 
signalling the intent that the tunnel is to be considered a virtual 
link.  Perhaps that has been removed because offhand I cannot find it.  I 
thought that was undesirable because it imposes a new meaning onto a 
possibly pre-existing behavior, and it is implicit rather than explicit.

Regards, Mark

---

From: Lars Eggert <[email-masked]>
Date: Fri, 23 Jan 2004 09:08:13 +0100

Mohan,

sorry for jumping in so late - time zones.

Mohan Parthasarathy wrote:
> My point is alternative 1 is not inferior on technical grounds. It is
> as good as IIPtran. The only problem i can see is its dependency on
> rfc2401. IIPtran may not have this dependency but you can have
> problems negotiating a transport mode SA if the other end thinks that
> it is tunnel mode.

The issue with alternative 1 is that nothing in 2401 (or 2401bis, for 
that matter) mandates it. As others have pointed out, implementations 
are free to provide the neccessary IP encapsulation for tunnel mode SAs 
without representing this imiplicit tunnel in the forwarding tables. 
(See section 4.2.1)

Now consider a virtual multi-hop topology, where some nodes implement 
alternative 1 and others do not. A dynamic routing protocol running over 
such a virtual topology will fail to exchange routes with the peers that 
do not implement alternative 1, as there are no interfaces to broadcast 
or multicast routing information over. (Unless these nodes implement 
alternative 3, where routing protocol implementation have to explicitly 
become IPsec-aware.)

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Thomas Narten <[email-masked]>
Date: Fri, 23 Jan 2004 08:08:58 -0500

A few misc points on this discussion.

1) My understanding is that this document has been reviewed by the
   IPsec WG, and they are OK with it being published as an
   Informational (non-WG) document. The main question is whether the
   l3vpn WG feels similarly.

2) This document does relate to the l3vpn WG, hence it is appropriate
   for this WG to review the document and raise any issues it feels it
   has. However, the WG has a number of things it can say, including:

    - basically OK, no need to bring it into the WG formally, i.e.,
      just go ahead and publish it as Joe has requested
    - OK, but here are some things that should be clarified/fixed (and
      then indicate what they are)
    - really conflicts with what we are doing and shouldn't be
      published until some of our other documents are completed (but
      so far, I don't sense that folk are  saying that) 
    - technically flawed, should not be published at all. (Again, I
      don't sense that folk are saying that)

  From a process perpsective, the RFC editor always asks the IESG if
  it is OK to publish an independent submission. This check is to
  ensure that the document isn't an end-run around an IETF effort (and
  in this case, I don't sense that it is, as the document's existance
  is hardly a secret to this or the ipsec WG).
  
3) Although the document may have been discussed in this WG before,
   what is at issue now is whether _this_ version of the document is
   OK to publish as an informational RFC at this time.

Thomas

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 23 Jan 2004 08:05:39 -0500

What he said.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Eric Rosen
Sent: Thursday, January 22, 2004 10:28 AM
To: Ross Callon
Cc: [email-masked]; Thomas Narten
Subject: Re: draft-touch-ipsec-vpn-06.txt

---

From: [email-masked]
Date: Fri, 23 Jan 2004 14:32:28 +0100

>       just go ahead and publish it as Joe has requested

Jeremy.

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2004 08:59:13 -0800

>       then indicate what they are)

To date, the suggestions and clarifications requested focus on IPsec WG 
issues, which have already been thoroughly vetted in that WG. Since that 
WG has disbanded, and since this document has already been approved to 
proceed as per (1), modifications suggested should be limited to issues 
directly relating to this WG.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2004 10:15:03 -0800

Mark Duffy wrote:

> personal submission RFCs than what any wg thinks.  Unless the policy is 
> to ask relevant wg's :-)

1) that's the policy
2) as I've stated, and as is available in the archives, we did as 
several WGs even before the IESG did.

> resulting packets seems a good one to me.  (And it is already embodied 
> in at least one document that is a product of this wg.)

It was embodied in this draft in 3/2000, and described in normative
publications of our project since 2000 as well.

> As an aside, I would be quite interested for the working group to take 
> on the effort to progress a *standard* for virtual links.  It should go 
> a step further and provide a way to convey to the far end what vpn 
> context a given tunnel is for.  Those deeply interested in this subject 
> might want to look at 
> <http://www.ietf.org/internet-drafts/draft-duffy-ppvpn-ipsec-vlink-00.txt>
> I think the basic approach presented is sound and appropriate.  I do 
> think the message gets a little lost in all the description of other 
> possible approaches  and why they don't work.  I found those 
> descriptions difficult to follow.
> 
> excessively rigid and literal.  E.g. in concluding that transport mode 
> may not be used between two gateways, and that protocol #4 
> encapsulations must be skipped past in evaluating SPD policy to look for 
> a transport header deeper in the packet.

Please review the IPsec WG mailing list archives on this issue. Rigidity 
is the defining characteristic of security specs (if not all specs, 
hopefully).

> completely oriented towards the policy based approach.  I am unaware 
> that it provides in any way for treating a tunnel mode SA as a virtual 

2401 cannot mandate only firewall-like (policy-based) approach; that
would defeat BITW architectures, which are specifically supported.

> Nit: the link numbers on figure 3 do not seem to match some references 
> to them in the preceding paragraphs.

That has already been corrected in an update that is pending this final
IESG review.

> Previous revisions of this document contained the concept that if one 
> sends an IKE proposal for transport mode protection for protocol #4, 
> then one is signalling the intent that the tunnel is to be considered a 
> virtual link.  Perhaps that has been removed because offhand I cannot 
> find it.  I thought that was undesirable because it imposes a new 
> meaning onto a possibly pre-existing behavior, and it is implicit rather 
> than explicit.
> 
> Regards, Mark

That's in section 4.2.4 (IKE impact), and has been reviewed by the IPsec WG.

Joe

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 23 Jan 2004 10:15:47 -0800

> without representing this imiplicit tunnel in the forwarding tables. 
Agreed. Is this a good enough reason for going with IIPtran ? I see that
this working group is already using IIPtran in one of the drafts. Would it
be a good fit in other scenarios that this group is considering ? e.g., CE-based
VPNs discusses both transport mode and tunnel mode and does not
recommend one over the other.

> alternative 3, where routing protocol implementation have to explicitly 
I just did a quick read of the Mark Duffy's document that he posted in the
other mail. It does seem to point out the pros and cons of the various
alternatives very well.Though i do not disagree with the IIPtran approach
(which i have implemented in the past), the pros and cons are not
evaluated against a standard set of requirements in this draft.

-mohan

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2004 10:20:11 -0800

> recommend one over the other.

That might be an interesting issue to discuss in Knight's draft (or a 
derivative thereof, as he mentioned).

> alternatives very well. Though i do not disagree with the IIPtran approach

The requirements are implicit - compliance with 2401 or interpretation 
thereof (e.g., that transport mode is OK between gateways because 
non-IPsec traffic is sourced/sunk at the gateways themselves - as 
clarified as allowable in 2401bis), and supporting dynamic routing.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2004 10:24:58 -0800

> alternative 1 does not have.

With the caveat that this part of the thread is focusing on issues that 
focus on IPsec issues that the IPsec WG has already reviewed...(the 
thread below on VPN-IDs is more L3VPN-specific).

IIPtran works with IKE fine (IKE to setup transport associations). The
interop problem is that IKE is setting up the tunnel too - and it's not
designed to setup IIPtran tunnels. It could easily be extended to do
that. The tricks are for mixed-mode IKE negotiation - i.e., using
modified IKE on an IIPtran node to trick a non-modified IKE to setup the
receive side of the tunnel correctly. That's not at all required - it's
discussed for completeness.

> My point is alternative 1 is not inferior on technical grounds. 

That depends on 'technical grounds'. Needing a protocol spec to indicate
the implementation details is (IMO) a technical flaw.

> It is as good as IIPtran.
> The only problem i can see is its dependency on rfc2401.

Actually, that it depends on modifying 2401 to include implementation
details; 2401 alone (as-is) is insufficient - exactly because it is
ambiguous in this regard.

> IIPtran may not have this

There is no trouble negotiating a transport mode SA over a tunnel
configured using a separate (e.g., tunnel configuration) protocol. The
issues raised in 4.2.4 are tricks to enable tunnel-mode receivers to
accept IIPtran packets - mixed mode, which (although it works, albeit
with IKE trickery) is not required.

> Why do you have to exchange SPIs ?

For some routing protocols - to advertise 10.0.0.1/spi#3 as having a
different routing metric than 10.0.0.1/spi#4. If a VPN-ID were available
(e.g., in the tunneling protocol), and used by the forwarding table, it
might be exchanged by the routing protocol (e.g., in a VR) as well. In
that case, the SPIs need not be exchanged, and are a moot point.

VPN-IDs help, or you can backoff and use IP addresses that are (like the 
VPN-IDs) unique per-node.

Discussions of the impact of VPN-IDs would be relevant to Knight's 
draft; our draft does not address L3VPNs directly.

> IKE would exchange SPIs and the

Given VPN-IDs and the proper forwarding implementation (VRs), I don't
need the SPIs anymore. The VPN-ID tells me which VPN a packet belongs to.

Using an IP address alone would be useful where VPN-IDs had not yet been
implemented or supported in the forwarding tables. I.e., it's a back-off
solution compatible with existing protocols.

Again, these issues should be relevant to Knight's draft.

Joe

---

From: Mark Duffy <[email-masked]>
Date: Fri, 23 Jan 2004 13:40:20 -0500

>would defeat BITW architectures, which are specifically supported.

Huh?  What does BITW change?  All implementation types (BITW, BITS, host, 
security gateway, etc.) of IPsec are required to implement the access 
controls aka policy orientation.

--Mark

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jan 2004 10:50:32 -0800

Mark Duffy wrote:
>>> that it provides in any way for treating a tunnel mode SA as a 
>>> virtual interface.  In fact it does much to obstruct that viz. SPD 
>>> policy and packet selectors.
>>
> Huh?  What does BITW change?  All implementation types (BITW, BITS, 
> host, security gateway, etc.) of IPsec are required to implement the 
> access controls aka policy orientation.
> 
> --Mark

BITW is my interpretation of how tunnel-mode-as-virtual-interface is 
perceived. That may not be correct; I won't defend that interpretation, 
since there are other problems. Others have defended it in the IPsec WG, 
which is why they are discussed as alternatives in our draft.

Joe

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 27 Jan 2004 10:52:36 -0800 (PST)

Hi Eric and WG,

Comments inline:

> violation of the IPsec standard is a further question.

I would second the above.

> the IPsec WG has failed to progress this draft.

Ditto.

> clearer  what the existing  practices and  what the  interoperability issues

Agreed. And this draft doesn't seem to help in that regard.

> for an individual draft on the topic to be published.

I agree that progressing this as an individual draft is odd as it
directly relates to CE-based VPNs. Furthermore it is not very clear whether this draft
also applies to the use of IPsec tunnel mode in PE based VPNs i.e. PE-PE IPsec tunnel mode.
If it does, it is very much related to the L3VPN WG.

rahul

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Jan 2004 11:08:15 -0800

> Hi Eric and WG,

agreed with the points made by Eric and Rahul.

Yakov.

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Jan 2004 09:21:31 -0800

> I would second the above.

It is a question that has already been discussed in the IPsec WG, and 
they have suggested that we move forward with our draft.

>>the IPsec WG has failed to progress this draft.

This has been addressed already.

...
>>unfortunately include  "CE-based VPNs using IPsec". 

This has been addressed already - this doc is more general than CE-based 
VPNs. Whether it applies to L3VPNs at all should be an issue for a draft 
such as Knight's - which we've already suggested. That draft should have 
a normative reference on this issue in the more general case, which 
would be ours.

Joe

---

From: Eric Rosen <[email-masked]>
Date: Wed, 28 Jan 2004 13:11:03 -0500

Joe> That draft should have a normative  reference on this issue in the more
Joe> general case, which would be ours. 

This is the sort  of statement that concerns me; it seems  to me that if you
are requesting publication  of an individual draft as  an informational RFC,
you cannot  then demand  (or even expect)  that any standards  document will
ever have a normative reference to it.  People should feel free to ignore it
or not, as they see fit.

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Jan 2004 10:13:24 -0800

> ever have a normative reference to it.  People should feel free to ignore it

Normative refs aren't just for standards.

FWIW, I wasn't requiring a normative ref (SHOULD, not MUST - perhaps I 
should have used caps?). I was suggesting it.

The utility of a ref would be that the Knight doc could focus on the 
L3VPN-specific issues, rather than recapitulating them. In that case, 
the ref would be normative in citing the explainations - not necessarily 
agreeing with them.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Jan 2004 10:17:25 -0800

> Normative refs aren't just for standards.

To be more specific, see:
http://www.rfc-editor.org/policy.html#policy.refs

"Normative references specify documents that must be read to understand 
or implement the technology in the new RFC, or whose technology must be 
present for the technology in the new RFC to work."

---

From: Eric Rosen <[email-masked]>
Date: Wed, 28 Jan 2004 13:34:46 -0500

> present for the technology in the new RFC to work." 

I have a  hard time seeing how your document would  fall into this category.

I just want to be sure we  are not setting the stage for a continuing series
of future conflicts regarding this document.

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Jan 2004 10:52:38 -0800

> I have a  hard time seeing how your document would  fall into this category.

"read to understand" - even if it's a differing viewpoint, it is one 
that was vetted through IPsec.

If you don't feel it should be cited, then don't.

> of future conflicts regarding this document. 

Agreed. But as an individual informational submission, there should be 
no conflict in that regard. You are always welcome to disagree.

Joe