Subject: [Tsvwg] Comments at IETF74 regarding draft-ietf-tsvwg-rsvp-security-groupkeying-04

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 14 Apr 2009 23:09:40 +0200

Bob, 

At the last IETF you made a comment at the microphone regarding 
http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-security-groupkeying

I wasn't there personally, but I believe your comment was along the
lines: "tunnel mode with address preservation is subject to change of
the outer address (like we pointed out for tunnel mode already), and
this should be mentioned explicitly." 

Do I capture your comment / suggestion correctly? 

If so, would the following change in section 6.6 address your comment,
or is it too simplistic? (suggested changes marked with ***)

--
6.6.  Applicability of Tunnel Mode with Address Preservation

   The document "Multicast Extensions to the Security Architecture for
   the Internet Protocol" [RFC5374] defines in section 3.1 a new tunnel
   mode: Tunnel mode with address preservation.  This mode copies the
   destination and optionally the source address from the inner header
   to the outer header.  Therefore the encapsulated packet will have the
   same destination address as the original packet, and be normally
   subject to the same routing decisions.  While [RFC5374] is focusing
   on multicast environments, tunnel mode with address preservation can
   be used also to protect unicast traffic in conjunction with group
   keying.

   Tunnel mode with address preservation, in conjunction with group
   keying, allows the use of IPsec AH or ESP for protection of RSVP even
   in cases where non-RSVP nodes have to be traversed.  This is because
   it allows routing of the IPsec protected packet through the non-RSVP
   nodes in the same way as if it was not IPsec protected.

***Note that IPsec tunnel mode with address preservation
   is also susceptible to the man-in-the-middle attack described in
section 
   6.2, since the outer header is not protected. This is a property of 
   IPsec tunnel mode; address-preservation does not change this
property.
--

Thanks for your help in reviewing this document! 
Michael

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 29 Apr 2009 19:00:24 +0100

Michael,

Sorry for holding you up on this. inline...

>this should be mentioned explicitly."

My comment wasn't just about "tunnel mode with address preservation" 
as far as I recall. It was about AH in tunnel mode in general, as 
shown in slide 4 (and discussed in S6.3 of the draft).

Slide 4 implied that AH tunnel mode only protects the inner IP 
header, while in fact I believe it also protects the immutable fields 
of the outer header (RFC4302 S3.1.2). Also your S6.3 omits to say AH 
tunnel mode protects the immutable fields of the outer header, 
although I think the spirit of the text implies that it does, when 
comparing ESP against AH. Whatever, it needs to be clearer. Am I right?

"6.3. Using IPsec AH
    ... IPsec AH tunnel mode ... protects the entire original IP
    packet, including the IP header, IP options or extension headers,
    plus the entire RSVP packet.
"
A/plus the immutable fields of the outer header/

At the IETF I believed the slide, so I pointed out this would allow 
the outer header to be changed en route. However, having looked up 
RFC4302, I think the criticism should have been that the wording 
needs to be made clearer that AH tunnel mode protects the immutable 
fields in the outer header too. If this is correct, then using AH in 
tunnel mode to protect RSVP PATH messages would not make them 
vulnerable to being diverted.

I've now read the latest version of the draft through (skipping 
unchanged parts) and, other than the above problem, it's a good one - 
a potentially useful addition to the RFC series. Thanks.

Cheers

Bob
>or is it too simplistic? (suggested changes marked with ***)

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research