Subject: 2401bis issues (possible) resolution

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 07 Oct 2003 13:38:47 -0400

In our weekly teleconference, we discussed the following items from the issues
list:

	40 Interface SPD selector vs. per-interface SPD
	50 Proposed change: tunnel vs. transport mode
	67 IPsec management traffic
	68 VPNs with overlapping IP address ranges
	69 Multiple protocols per SPD entry

We believe that these items are implementation-specific and/or not applicable
to implementations in general (this applies in particular to 50 and partially
to 68). We invite one last round of comments on these items --- if you feel
strongly, yell!

Reminder: the IPsec issue tracker is on https://roundup.machshav.com/ipsec/
-Angelos

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Oct 2003 14:01:22 -0700

> to 68). We invite one last round of comments on these items --- if you feel

Item 50:

The key issue we feel needs to be addressed is RFC2003 tunneled traffic, 
not traffic on a 'link' in general. Packets using 2003-style tunnels at 
a gateway originate and/or terminate at that gateway, and as such, are 
hosts for the purposes of IPsec conformance (for that tunnel). Thus 
RFC2401 already permits the use of transport mode on this traffic.

As noted before, this is discussed in detail in draft-touch-ipsec-vpn-06.txt

We feel that it would be useful for RFC2401bis to make this distinction 
clear, esp. since 2401 currently suggests that transport mode support is 
not required at gateways, i.e. in Sec 4.1:

>    Whenever either end of a security association is a security gateway,
>    the SA MUST be tunnel mode. 

It might be more specific to indicate that:

For traffic originating or terminating at a gateway, that gateway MUST 
support the functions of an IPsec host. In particular, traffic 
originating or terminating at that gateway that is tunneled over 
non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway 
that originates or terminates packets tunneled over non-IPsec 
mechanisms, for the purposes of that tunnel, MUST follow the IPsec host 
requirements rather than the IPsec gateway requirements.

Permitting the use of transport mode in this context goes specifically 
to the interaction between IPsec and RFC2003 tunnels, making it a 
protocol issue rather than merely an implementation issue.

Joe

---

From: Mark Duffy <[email-masked]>
Date: Tue, 07 Oct 2003 16:25:15 -0400

At 01:38 PM 10/7/2003 -0400, Angelos D. Keromytis wrote:
>In our weekly teleconference, we discussed the following items from the 
>issues list:
...
>         68 VPNs with overlapping IP address ranges
...
>to 68). We invite one last round of comments on these items --- if you feel

Hi Angelos and list,

As invited, I am yelling :-)

#68 (as I think you have acknowledged) consists of multiple parts, some of 
which are implementation issues but not all.  Part of #68 involved a 
capability in the protocol:

          b. They MUST negotiate a VPN subscriber ID using IKE, as
          noted above, to enable forwarding of inbound IPsec
          traffic after crypto processing.

When a security Gateway is operating on behalf of multiple contexts (e.g. 
multiple subscribers, or multiple ppvpn-style overlay addressing contexts), 
it is essential that the initiator be able to convey to the responder which 
context is being addressed.  In the absence of a capability to signal this 
in IKE, the only full-functioned alternative is for the SGs to maintain a 
separate IP address to use for each supported context.  This can waste a 
lot of addresses, and it isn't even as good anyway because it requires 
coordinated configuration on both ends to understand which IP address in 
each SG corresponds to which context.

My conclusion:  2401bis should support the concept of multiple contexts 
supported in an IPsec device, and IKE should provide a means to convey the 
desired context in the initial exchange.

Thanks, Mark

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 07 Oct 2003 19:03:15 -0400

Mark,

I agree about IKEv2 (although the means of implementing and the urgency of the
issue are open to debate). I don't agree about the 2401bis part, because it is
an implementation-specific issue (how the different contexts are implemented).
That issue was under 2401bis in the issue tracker, so we addressed the 2401bis
aspect of it; for the IKE part, we think it's not urgent enough to hold back
the document, although if Charlie can add such a thing quickly, it's OK with me.
-Angelos

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 07 Oct 2003 19:07:35 -0400

>RFC2401 already permits the use of transport mode on this traffic.

That is a different issue from what the text in #50 describes.

>protocol issue rather than merely an implementation issue.

This is a much more modest proposal than #50, which effectively allows a
gateway to insert an ESP header on another IP packet without doing tunneling.
-Angelos

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 8 Oct 2003 12:44:48 +0900 (JST)

> gateway to insert an ESP header on another IP packet without doing tunneling.

	i don't think Joe is suggesting insertion of ESP header in transit.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 8 Oct 2003 12:20:10 +0900 (JST)

> >    the SA MUST be tunnel mode. 

	I agree with Joe that the text above (section 4.1) is too restrictive.
	For instance, if security gateways are using GRE between them, there's
	no use in using tunnel mode SA to protect GRE (on unneeded IP header).

> protocol issue rather than merely an implementation issue.

	i agree with Joe on the above text.  and this is not just about 2003,
	but also GRE, 2893, 2473 (complicated version of 2893), 3056
	(not sure if anyone is interested in applying IPsec to this),
	2344, 2529 (almost obsolete).

itojun

---

From: Mark Duffy <[email-masked]>
Date: Wed, 08 Oct 2003 00:57:29 -0400

Hi Angelos,

It would seem odd to me to have the capability in IKE to address (specify) 
a particular context, but then not have any mention whatsoever of this in 
2401bis. But I suppose it doesn't really matter, I'll implement it anyway ;-)

--Mark

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Oct 2003 17:27:40 +0300

[Please when you send comments to list, use the issue number in the
subject, so it is easier for the others to search for other mails with
same issue]. 

>           traffic after crypto processing.

I do not think there is any need to negotiate the VPN subscriber ID
between the parties. The VPN subscriber ID is internal to the SGW, and
it is not going to trust anything the other end sends.

If I have understood correctly about the case it is something like
this:

	Corp A --------.			  +---- Client C
		     +-----+			  |
		     | ISP |-----{ Internet } ----|
		     | SGW |		          |
		     +-----+			  +---- Client D
	Corp B --------'

Where the ISP SGW is acting as VPN GW for both corporation A and
corporation B, and the clients connect to it using IPsec through the
internet. Corporations A and B both use 10.0.0.0/8 network, and give
out IP address to the clients from the same range. Now when the client
C connects to the ISP SGW it authenticates itself as [email-masked]. The
ISP SGW will now link that authenticated identity to the VPN
Subscriber ID of Corp-A, and attach all packets coming from the client
C to that VPN ID. When it is sending them out it will send to Corp A
interface, because it is also attached to the Corp-A VPN ID.

The ISP SGW will not be trusting client C to send him the VPN ID, as
if it would trust clinet C, the [email-masked] could send VPN ID of
corp-b instead and get access to the Corp B network.

So only way to get those VPN-IDs is through the configuration based on
the authenticated ID of the client, thus there is no need to negotiate
them in IKE.

This means that client C and D are normal IPsec clients, and they do
not have any special processing to be done. If Client C for some
reason wants (and is allowed) to be part of both Corp A and B
networks, then he can have two authenticated IKE identities
[email-masked] and [email-masked].

All the special processing of VPN IDs etc (or whatever local
processing the ISP SGW does) is inside the ISP SGW, thus it is purely
local implementation issue. 

> context is being addressed.

Do not use IP addresses as a IKE SA identities then. Use the dns names
or email addresses or something else. There is no need to use ip
addresses in those cases (or actually using ip addresses would be
quite bad, as it is not unique...). 

> In the absence of a capability to signal this 

There is no need for that. 

> desired context in the initial exchange.

I do not think this is general case that should be implemented in the
all IPsec stacks out there. It will be implemented as purely local
matter in some of the IPsec implementations, and there is no need to
have any kind of negotiation or changes to the IKE because of that. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Mark Duffy <[email-masked]>
Date: Wed, 08 Oct 2003 12:26:40 -0400

Hi Tero,

Thank you for your careful response, but still I disagree.  I think we may 
have different understandings of the scenarios to be addressed and the 
implications of those scenarios.  I have added some further comments below 
which I hope better explain the need as I see it.

--Thanks, Mark

At 05:27 PM 10/8/2003 +0300, Tero Kivinen wrote:
...
>it is not going to trust anything the other end sends.

It will trust what the peer sends because it authenticates the peer 
identity, and its configuration tells it which context(s) a given peer may 
access.  Semantically this is no different than placing separate SGWs there 
for each context -- each of them only allowing connections from certain peers.

>If I have understood correctly about the case it is something like

That is one case.  Two other cases are actually more important:
   1. The case where Clients C and D are replaced by fixed SGW's or perhaps 
even another shared "ISP SGW".   I.e. site-site rather than remote access.
   2. The PPVPN overlay case where the IPsec SAs secure "virtual links" 
between independed IP routing/forwarding contexts.

>C connects to the ISP SGW it authenticates itself as [email-masked].

I believe your statement above embeds the assumption that Clients C and D 
connect to the same logical SGW.  I.e. the ISP SGW presents the same 
identity, offers the same phase 1 policies, etc. to both of them.  I should 
like the ISP SGW to have the capability to present different identities and 
policies on behalf of Corp A and Corp B.

Your statement above also embeds an assumption that the context to be 
assigned  by the ISP SGW (responder) can be inferred from the identity 
asserted by the clients.  I think this is a highly undesirable condition to 
impose, especially for the PPVPN overlay case where the set of ISP SGWs 
(called PE routers in PPVPN-speak) will be supporting many contexts.  They 
will not want to have separate identities and credentials for each context!

>  The

No, because when client C sends the VPN ID of corp-b, it has to 
authenticate itself to the corp-b context.  The corp-b context does not 
have any configured policy that will let client C connect.

...

>have any kind of negotiation or changes to the IKE because of that.

I agree it should not affect implementations that don't need this 
capability.  However, implementations that need it need the IKE support.  I 
would envision that implementations that don't implement this will, as 
initiators, send their proposals without any context identifier.  And as 
responders they will discard proposals containing a context identifer.  And 
implementations that do implement this, when acting in the responder role, 
will either discard proposals that arrive with no context identifier, or 
process them under some default context.

Cheers,
Mark

---

From: Eric Vyncke <[email-masked]>
Date: Thu, 09 Oct 2003 16:28:16 +0200

>>to 68). We invite one last round of comments on these items --- if you feel

Angelos,

I'm yelling then ;-)

Transport mode is heavily used today by security gateways in 
conjunction with another tunneling mechanism (the choice is yours 
-- the objective is to use a tunnel understood by the kernel to 
apply packet forwarding based on a FIB).

When I write 'heavily', this means by dozens of organizations for 
their site to site VPN with 100 to 5000 nodes.

All what is needed for such VPN is that both RFC 2401bis and IKEv2 
allow the negotiation/SPD/SAD for transport mode between 2 SG. 

That's all.

Regarding the security aspects of transport mode combined with 
another tunneling mechanism (like IPinIP or GRE or ...), the fact 
that the selectors are simple (srcIP, dstIP, prot=4, srcPort=opaque, 
dstPort=opaque) has a positive impact on the configuration of 100's 
of nodes. Security can anyway be provided by applying the SPD on the 
tunnel interface (which is just another interface where a security 
policy can obviously be enforced).

NB: the text about 'link layer' encryption has much less importance for me.

I know that this topic has been beaten to death on the mailing list. But, please 
allow transport mode between SG or better allow a SG to also act as a host (which 
is EXACTLY what the SG/tunnel-endpoint is doing -- cfr Joe's email).

Regards

-eric

>Item 50:
>
>The key issue we feel needs to be addressed is RFC2003 tunneled traffic, not traffic on a 'link' in general. Packets using 2003-style tunnels at a gateway originate and/or terminate at that gateway, and as such, are hosts for the purposes of IPsec conformance (for that tunnel). Thus RFC2401 already permits the use of transport mode on this traffic.
>
>We feel that it would be useful for RFC2401bis to make this distinction clear, esp. since 2401 currently suggests that transport mode support is not required at gateways, i.e. in Sec 4.1:
>
>For traffic originating or terminating at a gateway, that gateway MUST support the functions of an IPsec host. In particular, traffic originating or terminating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003) MAY use transport mode. A gateway that originates or terminates packets tunneled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow the IPsec host requirements rather than the IPsec gateway requirements.
>
>Permitting the use of transport mode in this context goes specifically to the interaction between IPsec and RFC2003 tunnels, making it a protocol issue rather than merely an implementation issue.
>
>Joe
>
>
>

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Thu, 09 Oct 2003 10:51:13 -0400

Eric, nothing in 2401 (and 2401bis) precludes SGs from using transport mode.
Issue #50 is a lot more aggressive, as we read it.
-Angelos

>>The key issue we feel needs to be addressed is RFC2003 tunneled traffic, not 
>traffic on a 'link' in general. Packets using 2003-style tunnels at a gateway 
>originate and/or terminate at that gateway, and as such, are hosts for the pur
>poses of IPsec conformance (for that tunnel). Thus RFC2401 already permits the
> use of transport mode on this traffic.
>>
>>We feel that it would be useful for RFC2401bis to make this distinction clear
>, esp. since 2401 currently suggests that transport mode support is not requir
>ed at gateways, i.e. in Sec 4.1:
>>
>>For traffic originating or terminating at a gateway, that gateway MUST suppor
>t the functions of an IPsec host. In particular, traffic originating or termin
>ating at that gateway that is tunneled over non-IPsec mechanisms (e.g, RFC2003
>) MAY use transport mode. A gateway that originates or terminates packets tunn
>eled over non-IPsec mechanisms, for the purposes of that tunnel, MUST follow t
>he IPsec host requirements rather than the IPsec gateway requirements.
>>
>>Permitting the use of transport mode in this context goes specifically to the
> interaction between IPsec and RFC2003 tunnels, making it a protocol issue rat
>her than merely an implementation issue.
>>
>>Joe
>>
>>
>>

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Thu, 09 Oct 2003 11:22:41 -0400

Right --- the mods Joe suggested seem acceptable.
-Angelos

In message <[email-masked]>, Joe Touch writes:
>Except, as pointed out in my earlier post of 10/7/03:
>
>RFC2401, Sec 4.1:
>
>I.e., this explicitly precludes the use of transport modes between 
>gateways, except if considering that non-IPsec tunnels render those 
>gateways into hosts, so host rules should apply. Although that latter 
>interpretation technically complies with 2401, sec 4.1 could be 
>misconstrued to imply that gateways should not support transport mode. 
>That is where 2401bis could be clarified, as per (e.g.) the mods I 
>suggested in that earlier post.
>
>Agreed.
>>>I know that this topic has been beaten to death on the mailing list. But, pl
>ea
>>>se 
>>>allow transport mode between SG or better allow a SG to also act as a host (
>wh
>>>ich

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Oct 2003 08:29:05 -0700

Agreed.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 9 Oct 2003 21:27:18 +0300

> Right --- the mods Joe suggested seem acceptable.

I think we then should create new issue to issue tracker, with that
proposed text, so we can accept that and reject this?

>>> For traffic originating or terminating at a gateway, that gateway
>>> MUST support the functions of an IPsec host. In particular,
>>> traffic originating or terminating at that gateway that is
>>> tunneled over non-IPsec mechanisms (e.g, RFC2003) MAY use
>>> transport mode. A gateway that originates or terminates packets
>>> tunneled over non-IPsec mechanisms, for the purposes of that
>>> tunnel, MUST follow the IPsec host requirements rather than the
>>> IPsec gateway requirements.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Oct 2003 17:27:40 +0300

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Thu, 09 Oct 2003 11:22:41 -0400

---

From: Eric Vyncke <[email-masked]>
Date: Fri, 10 Oct 2003 12:04:26 +0200

Tero,

Regarding your point that SG should not trust the VPN-ID as received: this is for sure ;-) 

But, the VPN-ID can be used during the IKE_SA_INIT exchange in order for the SG to:
- check whether to continue the IKE exchange (i.e. custA has a contract for max 10 'tunnels')
- see what kind of security parameters to use (i.e. custA can enforce AES-256 for IKE or use only certs from this CA)
- ...

Then, during IKE_AUTH exchange, the SG will check whether the ID (as proven by the authentication) does indeed match the VPN-ID.

On a side note: the VPN-ID as exchanged during IKE_SA_INIT could potentially be different to the one used by the PPVPN on 'the other side' of the SG.

On another side note, the use of VPN-ID will be dictated most probably by an ISP/MSSP while the actual IKE ID will be selected by the customer. I'm afraid that forcing both parties to agree to a common naming for the ID (assuming that VPN-ID is rejected) will be a real pain in the real world...

Hope it helps

Just my 0.01 EUR

-eric

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 10 Oct 2003 13:15:23 +0300

Eric Vyncke writes:
> - see what kind of security parameters to use (i.e. custA can
>   enforce AES-256 for IKE or use only certs from this CA) 
> - ...

Now I am confused. Earlier I thought that VPN-ID was meant to be like
a traffic selector, i.e that you could create one IKE SA and then for
each IPsec SA you select which VPN-ID is used. You seem to be
proposing that VPN-ID is more like the IKE authentication ID, i.e the
identity of the other end.

For that kind of use you need to have separate IKE SA for each VPN,
and then the proper way to do that is use separate credentials and
authentication ID per VPN.

Adding VPN-ID as authentication ID propably would not be enough, as
you propably also need to identify the remote end box also, not only
the VPN where it belongs, thus you need VPN-ID and box id. Easiest
thing for that is to use something like dns-name or email address and
format that name so that it have VPN identifier part and box
identifier part inside, and map those strings to the actual local
VPN-ID through the configuration. 

> Then, during IKE_AUTH exchange, the SG will check whether the ID (as
> proven by the authentication) does indeed match the VPN-ID. 
> 
> On a side note: the VPN-ID as exchanged during IKE_SA_INIT could
> potentially be different to the one used by the PPVPN on 'the other
> side' of the SG. 
> 
> On another side note, the use of VPN-ID will be dictated most
> probably by an ISP/MSSP while the actual IKE ID will be selected by
> the customer. I'm afraid that forcing both parties to agree to a
> common naming for the ID (assuming that VPN-ID is rejected) will be
> a real pain in the real world... 

I think both VPN ID and IKE ID will be selected by the ISP, as both of
the boxes are controlled by ISP (unless there is yet another different
scenario), thus format of the IKE ID will be completely local matter
to the ISP.

Anyways, I think this is something that is not for general IPsec use,
but more specific case, thus I do not think we should include the
current issue #68 in the RFC2401bis now. I think we can write new
document to describe how to do that kind of things.

Can we agree on that now?
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Eric Vyncke <[email-masked]>
Date: Thu, 09 Oct 2003 16:28:16 +0200

Angelos,

I'm yelling then ;-)

That's all.

Regards

-eric

---

From: Mark Duffy <[email-masked]>
Date: Fri, 10 Oct 2003 10:23:06 -0400

>authentication ID per VPN.

Some folks participating in this discussion are talking about binding 
VPN-IDs to child SAs and others are talking about binding VPN-IDs to IKE 
SAs.  This is because people have different applications in mind and so 
they have different requirements.

>Can we agree on that now?

At this point I think that proponents of the VPN-ID signalling in IKE need 
to go off and write an I-D or I-Ds about extending IKEv2 to convey 
VPN-IDs.  I would hope to see 2401bis written in such a way that it will 
accommodate use of such signalling.  But, I don't know exactly what that 
means in terms of text in 2401bis.

--Mark

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Sat, 11 Oct 2003 13:37:44 -0400

Done.

In message <[email-masked]>, Tero Kivinen write

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Oct 2003 18:02:08 -0400

Joe,

You are right that 2401 makes a clear distinction between SG and host 
implementations in terms of required mode to be supported.  However 
it is not appropriate to require that an SG must also act like an 
IPsec host.

We distinguish 4 types of IPsec implementation contexts: SG, BITW, 
BITS, and native host.  the latter is special for several reasons, 
e.g.,  in that context it is reasonable to have access to the name of 
the target for an IPsec SA, as expressed by a user, whereas all other 
implementations can expect to have access only to addresses.  As a 
result, the form of SPD entries that a host must support is broader 
than the form that an SG (or BITS/BITW) must support. So, if only for 
that reason, it would not be appropriate to make a broad assertion 
that SGs must also support the functions of an IPsec host.

What we proposed to say is something like SGs MAY support transport 
mode, and MUST support tunnel mode, which would support the IP-in-IP 
or GRE tunneling over transport mode SAs, as well as 2401's mandated 
tunnel mode use.

Steve

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2003 15:27:56 -0700

Stephen Kent wrote:

> implementations in terms of required mode to be supported.  However it 
> is not appropriate to require that an SG must also act like an IPsec host.
> 
> We distinguish 4 types of IPsec implementation contexts: SG, BITW, BITS, 
> and native host.  the latter is special for several reasons, e.g.,  in 
> that context it is reasonable to have access to the name of the target 
> for an IPsec SA, as expressed by a user, whereas all other 
> result, the form of SPD entries that a host must support is broader than 
> the form that an SG (or BITS/BITW) must support. So, if only for that 
> reason, it would not be appropriate to make a broad assertion that SGs 
> must also support the functions of an IPsec host.

We define a host as a source or sink of packets. Other aspects - packet 
handling, etc., follow from this simple definition. This definition is 
certainly more terse than, e.g., sec 1.1.1 of RFC1122, but seems to be 
consistent as far as we have been able to discern.

We're not sure whether this defintion affects the need for other aspects 
of IPsec 'host' support. That support may not be needed for gateway 
'source or sink' services - e.g., mobile IP, multicast tunnels, GRE 
tunnels, IPIP tunnels, etc. But it would be needed if the gateway runs 
any IPsec transport-mode secured services that make it look like a 
traditional host (e.g., SNMP) But that's a completely different issue, 
one that the document is already sufficiently clear on.

> mode, and MUST support tunnel mode, which would support the IP-in-IP or 
> GRE tunneling over transport mode SAs, as well as 2401's mandated tunnel 
> mode use.

The commas in this are ambiguous. Is the following consistent with what 
you mean?

	SGs MAY support transport mode, and MUST support tunnel mode.
	Transport mode would support IP-in-IP or GRE tunneling
	over transport mode SAs.

Given that IP-in-IP is proposed standard and is used both for mobile IP 
and multicast, we still feel a SG MUST (or at least SHOULD) implement 
transport mode, though we appreciate that it might not be a full 'host' 
in other respects.

Joe

---

From: Jean-Francois Dive <[email-masked]>
Date: Tue, 14 Oct 2003 14:51:56 +0200

Hi all,

I believe 2 issues are discussed here and a new point that may have not
been discussed already (at least that i didn't saw in the mailing list
archive, please point me to the conclustions if i'am wrong).

- The addition of another ID field type in the selector for SG-SG
multi-customer environment: I just want to point the fact that IKEv1 has
that kind of facility as far as i can tell, no one support such usage so
far. As ID payload, for exemple ID type keyid, value "[customer1]blue"
could have achieved such thing, even though no traffic selector could be
passed. I believe that agreement on the format of such ID as much as all
the possible case of utilisation should stay outside of the standard,
but allowing a variable len field instead of a selector payload could be
used by some implementors or be left to other working groups. On the
other hand, as already mentioned, the same functionality could be
achieved using multiple 'sessions (init-auth-child-child-...)', one per
customer which sounds better to me as you add authentication on top of
it.

- The other point which i think is very important is what Eric mention
as an Id in the fist exchange. This is a big reason why people do use
aggressive mode with IKEv1. Without any other way of an exchange than by
IP address, protection suite for 'phase1' are biased and hard to
implement, this is the whole problem of responder profile/template
matching when a new exchange is received. I do understand that customer
wants identity protection, but we could again add a marker and leave
authentication where it is.

JeF.

--

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Oct 2003 09:44:16 -0400

At 15:27 -0700 10/13/03, Joe Touch wrote:
>Stephen Kent wrote:
>
>>Joe,
>>
>>You are right that 2401 makes a clear distinction between SG and 
>>host implementations in terms of required mode to be supported. 
>>However it is not appropriate to require that an SG must also act 
>>like an IPsec host.
>>
>>e.g.,  in that context it is reasonable to have access to the name 
>>of the target for an IPsec SA, as expressed by a user, whereas all 
>>other implementations can expect to have access only to addresses. 
>>As a result, the form of SPD entries that a host must support is 
>>broader than the form that an SG (or BITS/BITW) must support. So, 
>>if only for that reason, it would not be appropriate to make a 
>>broad assertion that SGs must also support the functions of an 
>>IPsec host.
>
>We define a host as a source or sink of packets. Other aspects - 
>packet handling, etc., follow from this simple definition. This 
>definition is certainly more terse than, e.g., sec 1.1.1 of RFC1122, 
>but seems to be consistent as far as we have been able to discern.

For IPsec we define hosts are ultimate source and sinks of packets, 
which is not quite the same. Security gateways are intermediary 
devices, typically fronting for a set of hosts on a LAN or enterprise 
net.  A bump in the wire (BITW) is a self-contained implementation, 
typically serving one device (host or router) located on an interface 
between that device and a network. the bump in the stack (BITS) 
implementation option is a retrofit approach to adding IPsec to a 
host, where the OS does not offer IPsec natively.

>We're not sure whether this defintion affects the need for other 
>aspects of IPsec 'host' support. That support may not be needed for 
>gateway 'source or sink' services - e.g., mobile IP, multicast 
>tunnels, GRE tunnels, IPIP tunnels, etc. But it would be needed if 
>the gateway runs any IPsec transport-mode secured services that make 
>it look like a traditional host (e.g., SNMP) But that's a completely 
>different issue, one that the document is already sufficiently clear 
>on.

OK.

>>mode, and MUST support tunnel mode, which would support the 
>>IP-in-IP or GRE tunneling over transport mode SAs, as well as 
>>2401's mandated tunnel mode use.
>
>The commas in this are ambiguous. Is the following consistent with 
>what you mean?
>
>Given that IP-in-IP is proposed standard and is used both for mobile 
>IP and multicast, we still feel a SG MUST (or at least SHOULD) 
>implement transport mode, though we appreciate that it might not be 
>a full 'host' in other respects.

Your indented text matches my intent.  I'll leave it to the list to 
decide whether the transport mode support ought to be a MUST, a MAY, 
or a SHOULD.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Oct 2003 18:01:26 +0300

> authentication where it is.

The question there is, "do you really have different phase 1
protections?". I think most of the cases the phase 1 protection is
irrelevant, as long as it is strong enough. Also there is no reason to
accept too weak phase 1 protection for anybody. Also the amount of
data encrypted etc is so small that it does not matter if what the
algorithm is.

With current IKEv2 document you can select the phase 2 algorithms
based on the identity of the initiator and also based on information
to whom the initiator wants to talk (i.e initiator can send responder
ID to whom he wants to talk before the responder selects the
algorithms.

I think this is enough. I do not see any good reason for the policy
that for the user X use 3DES and 3DES only for phase 1 protection and
for user Y use AES to encrypt phase 1 traffic.

I would think the policy would define that use the strongest one
proposed by the other end.

Note, that the main reason for the aggressive mode in the IKEv1 was
the use of preshared keys tied to the identity of the other end, not
the selection of phase 1 algorithms based on the identity. The main
mode didn't allow selecting of the pre-shared key based on the
identity, thus vendors were forced to use aggressived mode which
sent identity in clear thus allowed seeing the identity before
selecting the pre-shared keys.

The IKEv2 does not tie pre-shared keys to the phase 1 encryption keys,
thus the implementation can decrypt the IKE_AUTH message and see the
identity before verifying and generating the AUTH payloads using the
pre-shared key. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Eric Vyncke <[email-masked]>
Date: Tue, 14 Oct 2003 17:35:20 +0200

Tero

See in-line

>data encrypted etc is so small that it does not matter if what the

It is not only about negotiation of phase 1 protection, it can also be:
- for a shared SG: a hard limit on the number of IKE SA per customer
- selection of the right CA to send CERT_REQ (again in the case of a 
  shared SG with dozens or more customers each with its own CA)

>for user Y use AES to encrypt phase 1 traffic.

Agreed on this one, but, again there could be some corner cases; and
having worked with a lot of customers, I can guarantee you that
there are always weird ones requesting weird stuff.

>selecting the pre-shared keys.

This was indeed the main reason why IKEv1 is like it is. But, other
people re-used this 'feature' to do other services with it (like
the ones described above).

And, it would be really useful to keep the same services with
IKEv2.

>identity before verifying and generating the AUTH payloads using the

And, this is really a Good Thing (tm).

Just my 0,01 EUR

-eric

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Oct 2003 19:32:17 +0300

> - for a shared SG: a hard limit on the number of IKE SA per customer

This should be done only after the authentication, as only after then
you really know who the other end is. 

>   shared SG with dozens or more customers each with its own CA)

Send multiple certificate requests, i.e for each CA there are, or
simply leave out the certificate requests, and assume that you either
have the certificate, or that the client is configured to send you the
certificate anyways. 

> And, it would be really useful to keep the same services with

I think the best way to solve that kind of 'features' is to use
something like proprietary notification or something similar if you
cannot do it by the normal rules. I most of those cases there are ways
to get over with the problems by just doing little extra work.

I.e when you initially respond to the IKE SA you guess some policy and
use it. When you see the identity you verify your guess. If the guess
was incorrect you abort the negotiation, and request other end to
restart it, and mark it in your internal table that this IP address
should use this guess next time for next n minutes. Then when the
initiator restarts you select this different policy guess, and use
that instead. So all of these are doable, they might just need some
extra work. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/