Subject: [Ipsec] Issues remaining for draft-ietf-ipsec-rfc2401bis

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 12 Jan 2005 20:34:50 -0500

Based on the results of the IETF-wide last call of 2401-bis and the
comments from the IESG, these are the issues which Barbara and I believe
still need to be addressed in draft-ietf-ipsec-rfc2401bis-05.  If anyone
believes there are any issues that we missed, please let us know as soon
as possible.

Steve, Karen --- I understand that you have been communicating with some
of the AD's directly with respect to their concerns.  How far away are
we from reaching closure on these issues, and are there any that you
feel require specific attention from the working group?

Many thanks!!

					- Ted

Last Call Issues
================

Mark Duffy's 2401-bis fragment checking for Bypass/Discard (see ipsec
mailing list thread starting on October 5th through November 6th:

Date: Sat, 06 Nov 2004 23:36:25 -0500
From: Mark Duffy <[email-masked]>
Subject: Re: [Ipsec] 2401bis fragment checking for BYPASS/DISCARD

Ted,

Thank you for taking the time to re-read the thread and think about this
issue.  What I would seek is a minor change that allows discarding
non-initial fragments processed for BYPASS as an alternative to stateful
fragment checking of them.

I think this can be as simple as replacing this sentence in 7.4:
   An implementation MUST support stateful fragment checking to accommodate
   BYPASS traffic for which a non-trivial port range is specified.
with this one:
   An implementation MUST NOT forward fragmented BYPASS traffic
   without performing stateful fragment checking.

-------------------------------------

IESG Issues
===========

Harald Alvestrand:

Comment:
Reviewed by Brian Carpenter, Gen-ART

There are nits and small comments (review in document log), but no
show-stoppers.

[ i.e., Brian Carpenter's comments, see ipsec mailing list.  ]

--------------------------------------------------

Ted Hardie:

Comment:
This seems to have a mix of RFC 2026 and RFC 3668 boilerplates.

--------------------------------------------------

Ted Hardie:

In Section 4.1, the draft says:

In many secure multicast (or anycast) architectures, e.g., [RFC3740],
a central Group Controller/Key Server unilaterally assigns the Group
Security Association's (GSA's) SPI.  

3740 does not seem to mention anycast.  Is there a similar reference
for anycast?

--------------------------------------------------

Ted Hardie:

Section 4.4.1 uses 192.168 addresses, rather than the example prefix
192.0.2.x/24

--------------------------------------------------

Ted Hardie:

I found the use of "road warrior" in section 4.5.2 distracting.

--------------------------------------------------

Sam Hartman:

[issue 1, based on my iSCSI example]

I am beginning to believe that I have a somewhat general problem with
the balances and tradeoffs that the IPsec working group has chosen and
how those interact with the rest of the IETF.  The IPsec working group
is focusing on IPsec as its own application; system administrators and
users who configure IPsec because they want specific traffic
protected.  That's clearly an important use of IPsec.  However the
rest of the IETF continues to view IPsec as an appropriate tool for
providing security for other applications, protocols, etc.  In these
situations, IPsec (especially in native implementations) may need to
provide appropriate interfaces to these uses.  I'm concerned that the
2401bis model favors the first use too much.  Revisiting that issue
this late in the process would be inappropriate.  However I'd like to
focus on two cases where 2401bis seems to be problematic for the use
of IPsec as a security tool by higher layers.

The first issue is one I noticed late yesterday.  Section 7.4 mandates
stateful fragment handling for bypass and discard traffic if any of
the SPD selectors specify a specific port.     This means that when  I
start protecting traffic for one application, I end up having to
significantly complicate the packet processing for all my traffic.
Especially for native implementations, this seems unnecessary.  It
seems like  the real requirement is that I should not be able to
manipulate fragments to generate or receive unprotected traffic when
I'm expecting protected traffic.  It seems like keeping track of
whether a particular socket requires protected traffic would be
sufficient.  I'm not sure you can do better than 7.4 for other types
of implementations.

The second case is the case I described  eearlier where a host is
using IPsec both to provide security services for a higher layer and
to enforce specific policy as a security gateway etc.   Again, it
seems like you can do better than the current document  for native
implementations.    Virtual interfaces  based on MAC address seem like
the wrong solution; it only works if the protected traffic doesn't
share a router with unprotected traffic.  

I understand not all implementations need to support this sort of
functionality.  I'm concerned that it is not clear from the current
draft  that you might want to do this.  Also, I'm concerned that you
might end up choosing an implementation of this feature with hidden
implications.    

I suspect I need to be more concrete in what I want here.  I think
that all I'm asking for is clarifying text, but I haven't yet figured
out how I'd do what I want in the model so I'm having a hard time
determining if it is clear.

There are probably one or two rounds of discussion that need to happen
on this; I will try to be responsive so this does not bog down.

--------------------------------------------------

Sam Hartman:

[issue 2; Steve proposed two solutions both  of which are acceptable
to me.]

In 4.4.4.1, the two uses of the name pseudo-selector do not seem to be
comparable and so I don't understand why they are overloaded.  In the
first use, the name is an IKE identity used to contact a responder.
In the second use, the name is a local OS user for whom protection
services will be used or bypassed (or data discarded).  The local OS
is unlikely to use IKE identities; local naming is more likely to be
unix UIDs, Windows security IDs or something similar.  Why are these
two different things both called name; why should they be in the same
place in the SPD?

--------------------------------------------------

Sam Hartman:

[issue 3; I think we have rough agreement]

The example for X.500 distinguished names seems in the wrong order.
Shouldn't the country come last, not first?  In any event, a reference
to the string encoding of DNs that is being used should probably be
given; I'm assuming the example is relative to RFC 2253 or at this
point its successor.  If you are using a different string
encoding--particularly one with different ordering--it is even more
critical to cite.

--------------------------------------------------

Sam Hartman:

[issue 4; one outstanding question; probably the answer will be
sufficient for me to drop the issue.]

There doesn't in general seem to be a way to create an SPD policy that
uses IPsec if a SA is available  but is not used otherwise.  If the
peer is using an IKE identity other than an IP address the name
selector is adequate for this task.  However I don't understand how to
create an SPD entry of this type if the peer will assert an IP address
for its identity.  

--------------------------------------------------

Sam Hartman:

[issue 5; open question/clarification]

In section 5, the document claims that both outbound and inbound
packets must be checked against the SPD (or a cache).  This doesn't
actually appear to be what's described for inbound packets that use
IPsec protection.  The procedure for handling packets only checks them
against the SAD, not against the SPD.  The text claims that the SAD is
a cache of the SPD for inbound packets.  If this were true, everything
would be consistent.  However, earlier in section 4.4.1, the document
says that a system administrator should be given the opportunity to
decide what happens when the SPD is changed.  One of the options is to
allow extant SAs to continue.  If this option is taken, the SAD can
contain SAs that correspond to no SPD entry.  I believe the simplest
fix is to revise section 5 to claim that the SPD is consulted for
outbound packets and the SPD-I and SAD are consulted for inbound
packets.

--------------------------------------------------

Sam Hartman:

[issue 6; Steve proposed acceptable solution]

The text after rule 4 of 5.2 is confusing; Steve proposes making a
rule 5.

--------------------------------------------------

Sam Hartman:

[issue 7; agreed solution]

Section 7.4 should gain the same text about stateful fragment checking
not working in case of multiple paths as found in section 7.3.

--------------------------------------------------

Sam Hartman:

[issue 8; need to post Steve's text to tracker]

Steve Kent has new PAD text (4.4.3) which clarifies and extends the
PAD.  Russ has asked me to hold a discuss on this text.  I'm
discussing some comments about that text with Steve and Russ and
expect to amend my discuss once those discussions complete.

--------------------------------------------------

Sam Hartman:

[issue 9]
Appendix C:

There's text at the top of the appendix claiming that the module does
not compile because of a duplicate tag.  Could you please explain this
in more detail.

--------------------------------------------------

Sam Hartman:

Comment:
Section 6.1.2 creates requirements for incoming ICMP packets on the
protected side of the IPsec boundary.  As best I can tell the attacks
described in that section are potential problems for any Internet
gateway and have nothing to do with IPsec.  If so, why should the
IPsec architecture add requirements for additional administrative
controls to mitigate these attacks?  (I think the administrative
controls are a good idea; I'm just unsure why this specification is
the right place for them.)

--------------------------------------------------

Russ Housley:

Discuss:

  When will the module identifier be assigned for Appendix C?
  If you want IANA to do it, then it needs to be called out in
  the IANA Considerations section.

--------------------------------------------------

Russ Housley:

Comment:

  Section 4.1:
  s/Memory (TCAM0 features/Memory (TCAM) features/

  Section 4.4.1:
  s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/
  s/The SPD-SPD-S/The SPD-S/

  Section 4.4.2:
  s/Database(SAD),/Database (SAD),/

  Section 8.2.1:
  s/SAD entry When/SAD entry. When/

--------------------------------------------------

Alex Zinin:

Discuss:

How does the in/out-bound processing model defined in section 5 work
in the case of a VPN gateway? In particular, how does presence of
multiple routing realms and a two-stage forwarding process affect it
(imagine a gw that uses dynamic routing over the VPN tunnels protected
by IPsec transport mode as encapsulated packets leave the box)? What
about locally-originated messages, such as routing messages in this
case. I know how to make it work, the question is how the described
model addresses these scenarios.

--------------------------------------------------

Alex Zinin:

Section 4.4 Major IPsec Databases:

>    Forwarding vs Security Decisions
> 
>       The IPsec model described here embodies a clear separation between
>       forwarding (routing) and security decisions, to accommodate a wide
>       range of contexts where IPsec may be employed. Forwarding may be
>       trivial, in the case where there are only two interfaces, or it
>       may be complex, e.g., if there are multiple protected or
>       unprotected interfaces or if the context in which IPsec is
>       implemented employs a sophisticated forwarding function.

minor note: complexity of forwarding doesn't depend directly on the number of
local interfaces.

>                                                                 IPsec
>       assumes only that outbound and inbound traffic that has passed
>       through IPsec processing is forwarded in a fashion consistent with
>       the context in which IPsec is implemented.

What does the above statement really mean?

--------------------------------------------------

Alex Zinin:

Though Appendix E is not normative, I should note that it is rather
confusing.  Specifically, though the document states that no changes
to the forwarding function are introduced, the appendix mentions two
different forwarding tables--one for protected, and one for
unprotected side. Also, the representation of the forwarding tables
themselves creates an impression that routes usually include both
source and destination prefixes, which clearly isn't true (unless
we're talking about a special case of policy-based routing). Again, I
know how to make it work, but I don't think the doc is very good at
explaining this.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Karen Seo <[email-masked]>
Date: Thu, 13 Jan 2005 23:40:54 -0500

Ted,

Based on IESG feedback, we are in the process of resolving the Mark 
Duffy issue as part of a discussion of the same topic (with a 
somewhat different slant) with Sam Hartman.

Working with the IESG/AD's, we have put together a set of changes 
that we believe address the IESG comments in your email. I am working 
on incorporating them into the 2401bis draft for Steve's review when 
he returns from travel on Monday.  So I estimate we'll have the 
revised draft ready to submit to the IESG some time next week.

At the moment, I'm not aware of any issues for the working group 
except for the one you list below from Mark, but that could change as 
I go through the various IESG issues.

Thank you for your help,
Karen