Subject: Some comments on draft-tschofenig-v6ops-secure-tunnels

From: Eric Vyncke <[email-masked]>
Date: Wed, 09 Mar 2005 17:54:08 +0100

Just had a quick look this morning after the WG meeting on this document.

Some hopefully useful comments:

1) section 2.2, should be augmented because tunnel mode prevents the use of multicast (and more generally routing protocols -- cfr Joe Touch's I-D for IPv4) while transport mode does

2) section 2.2, IPsec will detect indirectly if the outer IPv4 addresses are wrong (spoofing among sites) because the decapsulation will fail since the crypto keys (for ESP and for AH) are based on <remote IPv4 address,SPI>

3) section 8, NAT-T for IKEv1 is actually a RFC and not an I-D, RFC 3948

4) section 11, security considerations, the obvious should perhaps be stated? Like DoS on the IPsec endpoint by flooding it with packets with the right SPI to force CPU intensive IPsec crypto operations. Or packet drop by a party along the tunnel path, ...

5) another use case scenario can be (and actually I've seen it deployed): using this IPsec protected IPv6 tunnel as a back-up link of a 'real native' IPv6 link in order to provide resiliency. This of course requires routing protocols hence the use of the 'transport mode' variant.

If required, I'll be ready to provide some text for the above points if the authors want.

Hope this helps to finalize this useful I-D

-eric

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 9 Mar 2005 16:41:58 -0800

Eric,

Thanks for your comments.

> 1) section 2.2, should be augmented because tunnel mode prevents the use of multicast (and more generally routing protocols -- cfr
Joe Touch's I-D for IPv4) while transport mode does
A tunnel mode SA can carry multicast traffic between two end points. Just define the SPD to contain multicast addresses.
I agree that we have to point out the issues mentioned in Joe Touch's draft somewhere..

> 2) section 2.2, IPsec will detect indirectly if the outer IPv4 addresses are wrong (spoofing among sites) because the
decapsulation will fail since the crypto keys (for ESP and for AH) are based on <remote IPv4 address,SPI>
SPI alone is sufficient looking up the SA for unicast traffic and this is how it is defined in the recent AH/ESP drafts.

> 3) section 8, NAT-T for IKEv1 is actually a RFC and not an I-D, RFC 3948
Ok, will fix it.

> 4) section 11, security considerations, the obvious should perhaps be stated? Like DoS on the IPsec endpoint by flooding it with
packets with the right SPI to force CPU intensive IPsec crypto operations. Or packet drop by a party along the tunnel path, ...
Perhaps we can add that..

> 5) another use case scenario can be (and actually I've seen it deployed): using this IPsec protected IPv6 tunnel as a back-up link
of a 'real native' IPv6 link in order to provide resiliency. This of course requires routing protocols hence the use of the
'transport mode' variant.
I don't know whether it is relevant to the current document or not. I will let Pekka answer this.

-mohan

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Mar 2005 03:21:41 +0200 (EET)

> Thanks for your comments.

Likewise, thanks.  Your review and support is appreciated.

> SPI alone is sufficient looking up the SA for unicast traffic and 
> this is how it is defined in the recent AH/ESP drafts.

Hmm.  Does this cause any issues if this is implemented either way?  I 
guess we'll need to support both..

>> 5) another use case scenario can be (and actually I've seen it 
>> deployed): using this IPsec protected IPv6 tunnel as a back-up link 
>> of a 'real native' IPv6 link in order to provide resiliency. This 
>> of course requires routing protocols hence the use of the 

(This is my opinion only, of course. :)

As far as I understand, the above is only an issue if the tunnel mode 
SA is not modelled as an interface (based on the touch-vpn, now 
RFC3884, right?  If it's an interface, it could be used to run a 
routing protocol (as long as it's not IS-IS :-) just fine?

I think we are already assuming that it's an interface, and this 
should not be an issue?

In any case, section 5.1 already describes transport mode 
router-to-router tunneling, which may or may not use lose ingress 
filtering capability depending on whether the transport mode is 
modelled as an interface or not.

So, I guess we already have all the technical bases covered (unless 
I'm missing something?), and the issue is just whether this usage 
scenario is should be explicitly mentioned in the draft.  I'd say not, 
because this seems to be a much more specific example case than the 
ones we currently have in the draft, and listing a specific one might 
be misleading.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 10 Mar 2005 09:48:28 -0800

> guess we'll need to support both..
SPIs are generated by the receiver. The 2401bis-draft, AH and ESP drafts
specify that SPI alone is sufficient for inbound demultiplexing for unicast SAs.
But if the implementation does something different, it would not break anything.
Perhaps, we can mention this.

> I think we are already assuming that it's an interface, and this 
I am not sure about this part. I have to read it again to see whether
we say this explicitly or not.

> modelled as an interface or not.
This is modeled as an interface because it is normally an IP-IP tunnel
+ IPsec.

> ones we currently have in the draft, and listing a specific one might 
Agreed.

-mohan

---

From: Eric Vyncke <[email-masked]>
Date: Tue, 22 Mar 2005 11:34:33 +0100

Sorry for late reply to your reply ;)

At 03:21 10/03/2005 +0200, Pekka Savola wrote:

...

>As far as I understand, the above is only an issue if the tunnel mode SA is not modelled as an interface (based on the touch-vpn, now RFC3884, right?  If it's an interface, it could be used to run a routing protocol (as long as it's not IS-IS :-) just fine?

Correct indeed. Except, that AFAIK IPsec/IKEv2 do not allow multicast traffic over ESP and as most routing protocols rely on multicast to discover neighbour. But, this is a kind of minor detail since a lot of implementations allow it.

...

>So, I guess we already have all the technical bases covered (unless I'm missing something?), and the issue is just whether this usage scenario is should be explicitly mentioned in the draft.  I'd say not, because this seems to be a much more specific example case than the ones we currently have in the draft, and listing a specific one might be misleading.

It is indeed a variation of router to router scenario as a parallel link. I would not call this a specific case but a variation.

Whether it is worth to add is another question of course ;-)

Hope it helps

-eric