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

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 13 Jan 2005 21:31:56 -0800

Hi Karen,

Though it is not a critical problem but as part of resolving the IESG
comments I had raised an issue, the following are the resolving
comments:-

Stephen Kent wrote:
> At 8:02 PM -0800 12/28/04, Vishwas Manral wrote:
> 
>> Hi Steve,
>>
>> As you said "such behavior by intermediate routers would tend to 
>> cause havoc with the traffic anyway, so I would hope that this would 
>> not be a common occurrence".
>>
>> Would we however want to put a comment regarding the same? The text 
>> to add could be "Changing DSCP values en-route can result in 
>> different class of packets on the same SA and SHOULD be avoided."
>>
>> Sorry for the confusion caused.
>>
>> Thanks,
>> Vishwas
> 
> 
> We could add an advisory statement that warns folks, e.g.,
> 
> "If significant reordering of packets occurs in an SA, e.g, as a 
> result of changes to DSCP values en route, this may trigger packet 
> discarding by a receiver due to application of the anti-replay
mechanism."
> Steve

This is certainly reasonable.

Let's try to construct an example where it might conceivably happen: a
video stream with two types of packet, i.e.
coarse and fine resolution. A possible reason for varying the DSCP is to
favor the coarse packets under congestion, so that they get through
promptly even if the fine detail is lost. But for that to happen en
route requires deep packet inspection (of non-encrypted packets) by a
device that magically knows that the data packets are a video stream.
This seems pretty unlikely. The normal scenario is that it's the video
source itself that marks the coarse and fine packets appropriately - and
that would lead to two SAs, not to an SA with a varying DSCP value.

     Brian

Thanks,
Vishwas
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Karen Seo
Sent: Friday, January 14, 2005 10:11 AM
To: Theodore Ts'o
Cc: [email-masked]; [email-masked]
Subject: [Ipsec] Re: Issues remaining for draft-ietf-ipsec-rfc2401bis

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

>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

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