Subject: comments on 2401bis-01 - Transport mode by SGs

From: Mark Duffy <[email-masked]>
Date: Tue, 02 Mar 2004 19:13:05 -0500

I just finished reading through draft-ietf-ipsec-rfc2401bis-01.txt and I 
found it much clearer than 2401.  A big thank you to the authors and other 
contributors!

I have a few questions on the content which I will spread over several 
messages.

Regarding use of transport mode by security gateways in sect. 4.1 it states:

    A transport mode SA is a security association typically employed
    between a pair of hosts to provide end-to-end security services. When
    link (vs. end-to-end) security is desired between two intermediate
    systems along a path, ...

It seems a bit of a misnomer to refer to this as "link security" since it 
may in fact span multiple links.  I propose referring to this instead as 
"intermediate system to intermediate system security."

                      ... transport mode MAY be used between security
    gateways or between a security gateway and a host.  In the latter
    case, transport mode may be used to support IP-in-IP [Per96] or GRE
    tunneling [FaLiHaMeTr00] over transport mode SAs.

Even in the former case (SG to SG) shouldn't the use of transport mode be 
limited to cases where some in-IP tunnelling mechanism is used?  But, it 
might not be IP-and-IP or GRE; it could be L2TP, MPLS-in-IP, etc.  So I 
suggest rewording this passage as follows:

    A transport mode SA is a security association typically employed
    between a pair of hosts to provide end-to-end security services. When
    security is desired between two intermediate systems along a path or
    between an intermediate and an end system, transport mode MAY be used
    between security gateways or between a security gateway and a host.
    In these cases transport mode may be used to secure any sort of
    in-IP tunneling. In these cases the security gateway(s) are in fact
    acting as end systems with respect to the in-IP tunnel packets to
    which transport mode IPsec is applied.

There are 2 additional mentions of "link security" later in the section 
that would also change:

Change
   "... security gateways MAY support a transport mode SA to provide link 
security for IP traffic"
to
   "... security gateways MAY support a transport mode SA to provide 
intermediate system to intermediate system security for tunneled IP traffic"

Change
   "If it supports transport mode, that should be used only when the 
security gateway is acting as a host, e.g., for network management, or to 
provide link security."
to
   "If it supports transport mode, that should be used only when the 
security gateway is acting as a host, e.g., for network management, or to 
provide intermediate system to intermediate system security for tunneled IP 
traffic."

--Mark

---

From: Thor Lancelot Simon <[email-masked]>
Date: Tue, 2 Mar 2004 21:55:36 -0500

> suggest rewording this passage as follows:

Why forbid two security gateways from using transport mode to protect
other SG-to-SG traffic?

---

From: Mark Duffy <[email-masked]>
Date: Tue, 02 Mar 2004 23:20:01 -0500

>Why forbid two security gateways from using transport mode to protect

By SG-to-SG traffic, do you mean packets whose source/dest addresses are 
the SGs?  I didn't mean to forbid any of that.  I think that WRT the 
non-tunneled traffic, the SG is acting as a host and the use of transport 
mode for this is described a few paragraphs further on in 2401bis.  Or, I 
can propose new text that explicitly includes that.

My points were that 1) SG-to-SG and SG-to-host should have the same rules 
applied to them, and 2) the type of in-IP tunneling doesn't matter and 
should not be limited to IP-in-IP and GRE.

As far as applying transport mode to transit packets (whose source/dest are 
not the SGs) 2401 proscribed that, I believe 2401bis-01 intends to 
proscribe it, and I had no intention of changing that.

--Mark

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Mar 2004 20:55:59 -0500

At 19:13 -0500 3/2/04, Mark Duffy wrote:
>I just finished reading through draft-ietf-ipsec-rfc2401bis-01.txt 
>and I found it much clearer than 2401.  A big thank you to the 
>authors and other contributors!
>
>I have a few questions on the content which I will spread over 
>several messages.
>
>It seems a bit of a misnomer to refer to this as "link security" 
>since it may in fact span multiple links.  I propose referring to 
>this instead as "intermediate system to intermediate system 
>security."

yes, "link" is not a great term, and we can consider something more 
descriptive. but because the access controls are applied only to what 
will be the outer header, we need to reinforce the fact that using 
transport mode here is very different.

>Even in the former case (SG to SG) shouldn't the use of transport 
>mode be limited to cases where some in-IP tunnelling mechanism is 
>used?  But, it might not be IP-and-IP or GRE; it could be L2TP, 
>MPLS-in-IP, etc.  So I suggest rewording this passage as follows:
>

not sure I am complete happy with the wording, but I get your point. 
we just gave examples for the sorts of tunneling that might be used. 
it was not intended to be a proscriptive list.

>
>There are 2 additional mentions of "link security" later in the 
>section that would also change:
>
>Change
>link security for IP traffic"
>to
>security gateway is acting as a host, e.g., for network management, 
>or to provide link security."
>to
>security gateway is acting as a host, e.g., for network management, 
>or to provide intermediate system to intermediate system security 
>for tunneled IP traffic."

thanks.

Steve