Subject: Issue 68 ("VPNs with overlapping IP address ranges")

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 14 Oct 2003 12:55:51 -0400

We discussed this issue in our weekly telecon...it appears that there are two
separate, but connected issues here:

a) Some kind of IKE notification to inform the SG which subscriber the 
initiator
   wants to talk to; this is something that should be resolved in IKEv2, most
   likely as an additional document.

b) Support in the IPsec stack (meaning 2401bis text) for the notion of 
different
   subscribers. This part is applicable to 2401bis and thus to this issue. How
   it is implemented should be left to the individual implementations. There
   may be some merrit in including a paragraph in 2401bis mentioning the issue;
   so:

    We solicit 1 paragraph describing the issue and the possibilities for
    implementing it, to be included in 2401bis. If such a paragraph does not
    materialize in a week (by our next telecon), we will simply drop the issue.

Cheers,
-Angelos

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Oct 2003 13:18:56 -0400

>     materialize in a week (by our next telecon), we will simply drop 

I just returned from a 2 week trip and am catching up on mail, lots of mail ...

Still, I am a bit concerned by this characterization. Having looked 
at the traffic on this issue, I did not see a clear description of 
how two implementations would signal the necessary info in a standard 
fashion.  So I think that topic 1, the IKEv2 extension, will be 
critical.

As for item 2 above, we think it is appropriate to discuss this issue 
and I thought we had proposed text to that effect.  That text noted 
that it was a local matter as to how one took traffic from multiple 
subscribers and mapped it to the right SPD, but one has to discuss 
this as part of the overall processing model, to ensure that the 
model is clear and as comp;lete as possible.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Oct 2003 15:10:34 -0400

At 14:50 -0400 10/14/03, Angelos D. Keromytis wrote:
>In message <p0600200dbbb1df3cd045@[128.89.89.75]>, Stephen Kent writes:
>>
>It may be critical, but it certainly isn't part of 2401bis. There is also some
>apparent confusion as to what exactly is needed (some people talking about
>Phase1 IDs for authentication, others about Subscriber IDs, and so on).

I think it will be critical for a standard, interoperable solution 
for PPVPNs. However, since we have yet to agree on exactly what is 
needed, and we are not putting this in IKEv2 now, it is not something 
that needs to be in 2401bis, as you said.

>There wasn't proposed text as such, just indications as to what might be
>included (items 1 and 2 in the issue description). As to the 
>proposed approach,
>(a) is certainly acceptable, but (b) and (c) seem outside the scope of 2401bis
>(suggesting use of NAT!)
>-Angelos

Telling folks what has to be done to make this work is within the 
scope of 2401bis, even if (heaven forbid!) NAT is needed. We 
discussed this with people who make these products and the feedback 
we got is consistent with the proposal.

Steve

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 14 Oct 2003 15:06:01 -0400

>that needs to be in 2401bis, as you said.

Then we're in agreement.
-Angelos

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 14 Oct 2003 14:50:22 -0400

There wasn't proposed text as such, just indications as to what might be
included (items 1 and 2 in the issue description). As to the proposed approach,
(a) is certainly acceptable, but (b) and (c) seem outside the scope of 2401bis
(suggesting use of NAT!)
-Angelos

---

From: Mark Duffy <[email-masked]>
Date: Wed, 15 Oct 2003 00:13:25 -0400

Here in response to the solicitation is a proposed text re multiple context 
support in 2401bis:

      IPsec devices supporting services such as: security gateway for 
multiple subscribers, IPsec-protected tunnel links for overlay networks, 
etc. MAY implement multiple separate IPsec contexts.  These contexts MAY 
have and use completely independent identities, policies, key management 
SAs, and/or IPsec SAs.  This is for the most part a local implementation 
matter.  However, a means for associating inbound proposals with local 
contexts is required.  To this end, if supported by the key management 
protocol in use, context identifiers MAY be conveyed from initiator to 
responder in the signalling messages, with the result that IPsec SAs are 
created with a binding to a particular context.

--Mark

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Wed, 15 Oct 2003 10:25:30 -0400

Good enough.