Re: [conex] Act bits and Positioning (Was Re: Fwd: Review: draft-ietf-conex-destopt-06)

[Mirja Kühlewind <[e-mail]>]

I also would prefer to say that the CDO MUST be first and give it a try 
and see what the IESG says. If there are concerns, we can still change 
it to MUST be among the first 3...

Mirja


On 12.09.2014 05:33, Suresh Krishnan wrote:
> Hi Bob/Mirja,
> Sounds fine to me as well. I can live with any value of X but the only
> one that really makes sense is 1 :-)
>
> Thanks
> Suresh
>
> -----Original Message-----
> *From:* Bob Briscoe [[e-mail]]
> *Received:* Tuesday, 09 Sep 2014, 1:44PM
> *To:* Mirja Kühlewind [[e-mail]]
> *CC:* Suresh Krishnan [[e-mail]]; Carlos Ucendo
> [[e-mail]]; ConEx IETF list [[e-mail]]
> *Subject:* Re: Act bits and Positioning (Was Re: [conex] Fwd: Review:
> draft-ietf-conex-destopt-06)
>
> Mirja,
>
> Agree with you on all 3 new responses:
> * act bits = 00
> * CDO SHOULD be first destopt, and MUST be among
> the first X destopts: that works for me.
>      X=3?
> * CDO is always in the destopt position before
> any IPsec, and ConEx doesn't work within an ESP tunnel.
>
>
> Bob
>
> At 15:19 09/09/2014, Mirja Kühlewind wrote:
>>Hi,
>>
>>see inline
>>
>>On 09.09.2014 09:59, Bob Briscoe wrote:
>>>Suresh,
>>>
>>>At 05:36 09/09/2014, Suresh Krishnan wrote:
>>>>Hi Bob,
>>>>   Thanks a lot for your comments. I will respond to two specific issues
>>>>that you brought up
>>>>
>>>>act bits being 01: Please note that the Conex option is a *destination*
>>>>option. Non conex-aware nodes on path will not even process the option.
>>>>So we do not need to be worried about the packet being dropped by
>>>>intermediate nodes, and we need to know if the destination does not
>>>>understand it. Hence I think this should stay as 01.
>>>
>>>I was aware that the act bits are only processed by the destination.
>>>
>>>My point was that ConEx only requires sender support (ie. you can have
>>>ConEx on one half-connection but not the other - there is no need to
>>>negotiate ConEx for a connection). So it would be very bad for a
>>>destination to drop a packet just before delivering it to the
>>>destination process just because it doesn't recognise a ConEx header
>>>that it doesn't need to understand anyway.
>>>
>>>Note to Mirja: Given this misunderstanding, perhaps the draft should
>>>give a reason:
>>>          "The act bits MUST be 00, because a ConEx packet needs to be
>>>passed to the destination process even if the destination does not
>>>understand ConEx."
>>I agree with Bob, as the receiver does not need
>>to proceed the option in our case at all and it
>>does even know if it has to be there. Suresh?
>>
>>>
>>>
>>>>CDO as the first option: As you rightly note, this is just a performance
>>>>optimization. I do believe that the performance penalty for conex-aware
>>>>nodes will be pretty severe if they need to process all destination
>>>>options before deciding if the CDO is present or not.
>>>
>>>Surely a ConEx node can stop when it gets to the CDO option (which will
>>>usually be first). It doesn't need to continue and process all the other
>>>options within the destopt header.
>>>
>>>>Please note that
>>>>this needs to be done on *all* packets passing through the conex aware
>>>>node.
>>>
>>>On packets without a destopt that is quick.
>>>
>>>The really bad case is for packets from senders that don't support ConEx
>>>but are using many other destopts. Then the on-path ConEx node would
>>>walk along every destopt until the end.
>>>
>>>>I do think it is OK to change the MUST to a SHOULD but with a
>>>>severe warning.
>>>
>>>OK, thanks.
>>>
>>>Would it be OK to say "As an optimization, a ConEx implementation MAY
>>>limit the depth of its search for CDO to two or three destination options"?
>>My assumption was that search for the CDO if
>>multiple options are present is not feasible in fast path.
>>
>>So if the CDO is not first, there are two options:
>>1) forward the packet to slow path
>>2) ignore the CDO
>>
>>Actually case 1) is probably no option because
>>this would forward all present traffic to slow
>>path because none of the traffic has a CDO at all.
>>
>>2) is at least not feasible for something like a
>>policer that really needs to look at all ConEx-enable packets.
>>
>>Limiting the search depth, would translate into
>>"the CDO SHOULD be the first option and MUST be
>>among the first X options"... is that a solution?
>>
>>
>>Bob, see further below...
>>
>>>
>>>
>>>I have also added to my response to Mirja below, with an extra thought
>>>about ESP tunnels (inline - search for 'ESP tunnel' - it's a long way
>>>down!)...
>>>
>>>
>>>>Cheers
>>>>Suresh
>>>>
>>>>On 09/08/2014 06:17 PM, Bob Briscoe wrote:
>>>> > Mirja,
>>>> >
>>>> > At 16:57 03/09/2014, Mirja Kühlewind wrote:
>>>> >> Hi again,
>>>> >>
>>>> >>
>>>> >> On 28.08.2014 22:05, Bob Briscoe wrote:
>>>> >>>>>>>>>>>> * Suggested deleting example of Not-ConEx-capable packets
>>>>(see
>>>> >>>>>>>>>>>> separate thread to conex-tcp-modifications authors about
>>>>TCP pure
>>>> >>>>>>>>>>>> ACKs).
>>>> >>>>>>>>>>> I can remove the example but not sure why you are suggesting
>>>> >>>>>>>>>>> this. If
>>>> >>>>>>>>>>> you actually imply that the X bit should never be zero
>>>>that we
>>>> >>>>>>>>>>> have to
>>>> >>>>>>>>>>> discuss if the X bit is needed at all.
>>>> >>>>>>>>>> I have never thought the X flag was needed. There's
>>>>probably some
>>>> >>>>>>>>>> email
>>>> >>>>>>>>>> on the list somewhere in the past from me that says that.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> As I put in one of the comment bubbles:
>>>> >>>>>>>>>> "The only need I can see for the X-flag is if
>>>> >>>>>>>>>> the Reserved field gets used in future for
>>>> >>>>>>>>>> something in addition to ConEx. Then there
>>>> >>>>>>>>>> would be a need to identify packets that
>>>> >>>>>>>>>> are not ConEx-capable but still carry the
>>>> >>>>>>>>>> CDO option (for the new reason)."
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Can anyone think of a use for the X flag?
>>>> >>>>>>>>> I thought the X bit unset means: I'm a ConEx aware sender and i
>>>> >>>>>>>>> want to
>>>> >>>>>>>>> follow the rules but I don't have any feedback for this
>>>>(control)
>>>> >>>>>>>>> data
>>>> >>>>>>>>> so I'm unable to give you useful ConEx information and if
>>>>you use
>>>> >>>>>>>>> this
>>>> >>>>>>>>> packet for your estimation of the current congestion level, you
>>>> >>>>>>>>> might
>>>> >>>>>>>>> underestimate it.
>>>> >>>>>>>>>
>>>> >>>>>>>>> Doesn't that make sense...?
>>>> >>>>>>> Not to me. What does "feedback for this (control) data" mean?
>>>>Feedback
>>>> >>>>>>> is about a path used by a 5-tuple. This control data is about
>>>>to be
>>>> >>>>>>> sent
>>>> >>>>>>> over such a path. If the sender has feedback about that path, the
>>>> >>>>>>> feedback applies to everything sent over the path, at the IP
>>>>layer,
>>>> >>>>>>> whatever categorisation the next packet has at L4.
>>>> >>>>>> If you do not get any feedback on a path, e.g. a receiver only
>>>>sending
>>>> >>>>>> ACKs, you will never be able to send any ConEx markings. So
>>>>what's the
>>>> >>>>>> point about marking a packet as ConEx-enabled?
>>>> >>>>> OK, this is a good example for when a ConEx-enabled flag might be
>>>> >>>>> useful. However,...
>>>> >>>>>
>>>> >>>>> ...This doesn't justify marking pure ACKs as not-ConEx-enabled.
>>>>If a
>>>> >>>>> sender sends a pure ACK now, all it knows is that it might not have
>>>> >>>>> enough feedback to be able to set ConEx markings on a whole
>>>>sequence of
>>>> >>>>> packets later in the flow,... but only if it keeps sending
>>>>solely pure
>>>> >>>>> ACKs from now on. However, a sender can't be sure that it won't
>>>>have
>>>> >>>>> enough feedback in future, because usually an app (let alone the
>>>> >>>>> transport layer) cannot predict whether there will be more data
>>>>to send
>>>> >>>>> later, even if it's not sending any now.
>>>> >>>>>
>>>> >>>>> Once a sender has had no feedback for at least a round trip, it
>>>>has 2
>>>> >>>>> options for subsequent packets:
>>>> >>>>> a) turn off ConEx-enabled;
>>>> >>>>> b) keep sending packets with ConEx-enabled set, but
>>>>conservatively add
>>>> >>>>> some credit.
>>>> >>>>>
>>>> >>>>> Even if it subsequently sends some data, it will still have to
>>>>do (a) or
>>>> >>>>> (b) on these data packets, at least for one further round trip,
>>>>until it
>>>> >>>>> gets the feedback. So this is nothing to do with whether the packet
>>>> >>>>> being sent is a pure ACK. It is to do with whether feedback has
>>>>recently
>>>> >>>>> been received.
>>>> >>>> Okay, rewrote the paragraph slightly:
>>>> >>>>
>>>> >>>> "If the X bit is zero all other three bits are undefined and thus
>>>> >>>> should be ignored and forwarded unchanged by network nodes. The X
>>>>bit
>>>> >>>> set to zero means that the connection is ConEx-capable but this
>>>>packet
>>>> >>>> MUST NOT be accounted when determining ConEx information in an audit
>>>> >>>> function. This can be the case if no feedback on the congestion
>>>>status
>>>> >>>> is (currently) available for e.g. for control packets (not carrying
>>>> >>>> any user data). As an example a TCP receiver that only sends pure
>>>>ACKs
>>>> >>>> will usually send them as ACK are usually not ECN-capable as ACK
>>>> >>>> usually are not ECN-capable and TCP does not have a mechanism to
>>>> >>>> announce ACK lost. Thus congestion information about ACKs are not
>>>> >>>> available."
>>>> >>>>
>>>> >>>> Is this okay?
>>>> >>> The main problem is saying 'not available *for* control packets'. But
>>>> >>> just changing 'for' to 'from' would still make this too unclear to be
>>>> >>> understood.
>>>> >>>
>>>> >>> Also need to:
>>>> >>> * Make it clear the example is TCP-specific.
>>>> >>> * Focus on loss first, then ECN.
>>>> >>> * 'mechanism to announce ACK loss' is not really understandable.
>>>> >>> * Avoid 'control packets', which is too general, given this is an
>>>> >>> example, so it can be specific.
>>>> >>> * Nit: duplicated word (for e.g. for) and duplicated phrase (as
>>>>ACK are
>>>> >>> usually not ECN-capable as ACK usually are not ECN-capable).
>>>> >>>
>>>> >>> How about:
>>>> >>>
>>>> >>> First 2 sentences unchanged, then...
>>>> >>> "This can be the case if no congestion feedback is (currently)
>>>>available
>>>> >>> e.g. in TCP if one endpoint has been receiving data but sending
>>>>nothing
>>>> >>> but pure ACKs (no user data) for some time. This is because pure
>>>>ACKs do
>>>> >>> not advance the sequence number, so the TCP endpoint receiving them
>>>> >>> cannot reliably tell whether any have been lost due to congestion.
>>>>Pure
>>>> >>> TCP ACKs cannot be ECN-marked either [RFC3168]."
>>>> >> Fine for me. Done.
>>>> >>
>>>> >>
>>>> >>>>>> Further note, in the TCP mods we only look at the payload
>>>>because we
>>>> >>>>>> assume, for simplification, all packets have the same size.
>>>>Therefore
>>>> >>>>>> a packet that carries no data would not decrease the CEG/LEG.
>>>>If ACKs
>>>> >>>>>> should get marked, we need to rewrite all this stuff in the tcp
>>>>mods
>>>> >>>>>> doc...
>>>> >>>>> I don't think we should avoid changing tcp-mods if its 'not right'.
>>>> >>>>>
>>>> >>>>> I hope you see the problem from my explanation above - whether
>>>>there is
>>>> >>>>> enough feedback /now/ to ConEx-mark a packet has nothing to do with
>>>> >>>>> whether the packet being sent /now/ is capable of generating
>>>>feedback
>>>> >>>>> /in the next round/.
>>>> >>>>>
>>>> >>>>> If you want to make a simplifying assumption, it is on the safe
>>>>side for
>>>> >>>>> a sender to assume that all incoming feedback is about packets
>>>>of the
>>>> >>>>> same size. It's not safe for a sender to assume that all packets
>>>>it is
>>>> >>>>> sending are the same size. Anyway, it knows what size it is
>>>>sending, so
>>>> >>>>> it doesn't need this simplification.
>>>> >>>> Okay, the assumption is (only) that feedback is based on packets
>>>>that
>>>> >>>> are the same size. If we send you a packet we of course decrease the
>>>> >>>> LEG/CEG by the actually payload bytes. But taking this assumption be
>>>> >>>> simply do not account for headers at all (nor incoming neither
>>>> >>>> outcoming) because we can anyway just estimated the header bits and
>>>> >>>> there simply assume it will equal out. Which mean if we send a pure
>>>> >>>> ACK we will not decrease the LEG/CEG because there are no payload
>>>> >>>> bytes. I believe that this simplification makes thing much
>>>>simpler and
>>>> >>>> is therefore useful but will not allow for marking pure ACKs...
>>>> >>> I thought the earlier definition said that ConEx accounts for the
>>>>size
>>>> >>> of the IP header that contains the CDO and everything within it.
>>>>Also,
>>>> >>> there's the TCP header size on a pure ACK.
>>>> >> Yes, especially when a network node accounts
>>>> >> ConEx marks. But in the (TCP) sender we just
>>>> >> don't care about the header bits for
>>>> >> simplification. We are aware that all bits will
>>>> >> be accounted but as we assume equal size packets that should be fine.
>>>> >>
>>>> >>
>>>> >>> That's the basis on which I am assuming that pure ACKs are worth
>>>> >>> counting. A pure ACK will count as at least 86B (and more if there
>>>>are
>>>> >>> additional TCP options or IP extensions).
>>>> >>>
>>>> >>> IPv6 header: 40B
>>>> >>> CDO dest opt: 6B
>>>> >>> TCP header: 40B
>>>> >>> Total: 86B
>>>> >>>
>>>> >>> If there are more IP extensions, I guess it will be hard for TCP
>>>>to know
>>>> >>> though.
>>>> >> Yes, so how should I implement that?
>>>> > I guess just assume that any IP extensions will
>>>> > be constant on every packet in a flow, therefore
>>>> > assuming none will be similar to assuming some.
>>>> >
>>>> >>>> You didn't convince me (yet) that this should be changed but this
>>>> >>>> would need to be changed in the tcp mods doc and not this one
>>>>anyway.
>>>> >>> Agreed (that this would affect tcp-mods, not destopt).
>>>> >>>
>>>> >>> What is 'this' that you aren't yet convinced by?
>>>> >> 'this' is the fact that I need to changed
>>>> >> something in the tcp mods document. I might
>>>> >> remove the statement (if existent) that control
>>>> >> packets should be not-ConEx capable but I would
>>>> >> still like to recommend it because I believe it
>>>> >> makes things overly complicated otherwise. The
>>>> >> point is I believe that at the location in the
>>>> >> (Linux) code where you implement the counting,
>>>> >> you don't even have the information how large
>>>> >> the pure ACK will be in the end...
>>>> > See next comment.
>>>> >
>>>> >>>>> The simplification I propose (that feedback is all about the
>>>>same size
>>>> >>>>> packets, rather than all the sent packets are the same size) is
>>>>likely
>>>> >>>>> to be pretty good, given the receiver doesn't get loss or ECN
>>>>info about
>>>> >>>>> pure ACKs, so they are automatically removed from the set of
>>>>packets
>>>> >>>>> that the sender assumes to be the same size. And, and if some of
>>>>the
>>>> >>>>> feedback is about smaller data packets, at least this
>>>>simplification
>>>> >>>>> will always be on the safe side.
>>>> >>>>>
>>>> >>>>> If I correctly understand the simplification you propose, a
>>>>ConEx sender
>>>> >>>>> will more often under-declare congestion than over-declaring,
>>>>which is
>>>> >>>>> not safe.
>>>> >>>> I don't believe so. Was this just of a different understanding of
>>>>what
>>>> >>>> we proposed or can you explain further...?
>>>> >>> I thought you were proposing that a TCP sender assumes all the
>>>>packets
>>>> >>> it sends are full-sized, even if they aren't. But I believe you have
>>>> >>> said that is not what you proposed.
>>>> >> No, when reducing the congestion counter(s) we
>>>> >> use the actual number of payload bytes. We also
>>>> >> use the real number of acknowledged bytes to
>>>> >> increase the counter(s). We simply do not care
>>>> >> about the header bytes at all assuming that on
>>>> >> average all packets have the same size and
>>>> >> therefor the number of (marked) header bytes
>>>> >> (either ECN or ConEx) in total will be about right.
>>>> > OK. I understand now.
>>>> >
>>>> > Ultimately TCP has to put a number in the Data
>>>> > Offset field, so it has to know the size of its
>>>> > own header. However, for an initial
>>>> > (experimental) implementation, if you need your
>>>> > proposal to assume all TCP options within one
>>>> > flow are the same size, it would be reasonable
>>>> > (it's not actually true, e.g. SACK, but there
>>>> > should at least be no bias, so you will overstate as much as
>>>>understate).
>>>> >
>>>> > You say earlier that it is too complicated to
>>>> > implement code within TCP that knows the size of
>>>> > a pure ACK. If TCP code doesn't know the size of
>>>> > a TCP header, then Linux must be using magic
>>>> > instead of code. Because, surely, the whole point
>>>> > of the TCP code is to write a TCP header.
>>>> >
>>>> >>>>>>>>>>>> ==Fast-path==
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> * CDO as first destination option: changed from MUST to
>>>>SHOULD
>>>> >>>>>>>>>>>> (with
>>>> >>>>>>>>>>>> an example of when not to).
>>>> >>>>>>>>>>> I believe this really needs to be a MUST. I know that might
>>>> >>>>>>>>>>> restrict
>>>> >>>>>>>>>>> the use of ConEx with potential other options that might
>>>>have the
>>>> >>>>>>>>>>> same
>>>> >>>>>>>>>>> requirement (for different reasons). But if you don't put
>>>>a MUST
>>>> >>>>>>>>>>> here,
>>>> >>>>>>>>>>> you cannot implemented the suggested way in the fast path.
>>>> >>>>>>>>>> A SHOULD still means it will be the first option in all
>>>>current
>>>> >>>>>>>>>> implementations. However, I suggest a SHOULD, precisely
>>>>because
>>>> >>>>>>>>>> performance reasons are not absolute, so they don't require a
>>>> >>>>>>>>>> MUST. If
>>>> >>>>>>>>>> another dest opt cannot work at all unless it is first,
>>>>that would
>>>> >>>>>>>>>> be a
>>>> >>>>>>>>>> valid reason for CDO coming second, because it still works,
>>>>it's
>>>> >>>>>>>>>> /just/
>>>> >>>>>>>>>> slower.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> The IESG will (rightly) be very wary of any draft that says an
>>>> >>>>>>>>>> option
>>>> >>>>>>>>>> MUST be the first option.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> I suggested the following text after this: "(This is not
>>>> >>>>>>>>>> stated as a 'MUST', because some future destination option
>>>>might
>>>> >>>>>>>>>> need to
>>>> >>>>>>>>>> be placed first for functional rather than just performance
>>>> >>>>>>>>>> reasons.)"
>>>> >>>>>>>>> So our fast path implementation must simply assume that
>>>>there is no
>>>> >>>>>>>>> CDO
>>>> >>>>>>>>> in case it cannot find it as the first option. Otherwise all
>>>> >>>>>>>>> non-ConEx
>>>> >>>>>>>>> packets would need to go to the slow path to make sure there
>>>>is no
>>>> >>>>>>>>> ConEx
>>>> >>>>>>>>> option. That means to me that this must be a MUST...?
>>>> >>>>>>> OK, I see the problem, but how much of a performance problem
>>>>would it
>>>> >>>>>>> really be for the fast path of a ConEx function to step along
>>>>dest
>>>> >>>>>>> opts
>>>> >>>>>>> until it gets to CDO then stops (rather than stop if CDO is not
>>>> >>>>>>> first)?
>>>> >>>>>> So that's the different between you looking at one bit at a
>>>>defined
>>>> >>>>>> position or having a chain of conditional look-ups where the
>>>>length is
>>>> >>>>>> unknown. I believe that is something you would avoid to
>>>>implement in
>>>> >>>>>> fast path as the processing time is not fixed anymore... that
>>>>would be
>>>> >>>>>> my guess but I'm not an expert in this area.
>>>> >>>>> AFAICT, fast path implementations generally work along sequences of
>>>> >>>>> extensions. So I don't think this is a problem. Bear in mind
>>>>that we are
>>>> >>>>> not asking general fast path forwarding implementations to do
>>>>this. Only
>>>> >>>>> ConEx functions specifically written to find the ConEx
>>>>header.{Note 1}
>>>> >>>>>
>>>> >>>>> {Note 1} OK, we do suggest that general forwarding functions
>>>>could do
>>>> >>>>> DoS protection using the ConEx header. But that's stated as
>>>>optional and
>>>> >>>>> 'aspirational'. If such an experiment proves useful, you never
>>>>know,
>>>> >>>>> there could be demand for ConEx to migrate into the hop-by-hop
>>>>options
>>>> >>>>> (according to the v6 spec, hop-by-hop and dest options share the
>>>>same
>>>> >>>>> option number space, so this would be a straightforward
>>>>migration, just
>>>> >>>>> moving where the CDO is placed, but using the same option number
>>>>and
>>>> >>>>> format).
>>>> >>>> There might be also further use cases for e.g. traffic management or
>>>> >>>> multipath routing where general forwarding nodes need to access this
>>>> >>>> information.
>>>> >>>>
>>>> >>>> So what's the solution here?
>>>> >>> I think this will get thrown back by the IESG if we say 'MUST be
>>>>first'.
>>>> >>> And I think 'SHOULD be first' is a doable implementation for
>>>>ConEx-aware
>>>> >>> nodes. That is sufficient for experimental. Any experiments where
>>>> >>> general forwarding nodes access ConEx will already be reading a
>>>>destopt
>>>> >>> at every hop, which is not what was intended, but it would be doable
>>>> >>> just for an experiment that wanted to prove ConEx has wider uses.
>>>> >> I know that this might be a problem with IESG review, but... it's
>>>>broken...
>>>> >>
>>>> >>> Everyone involved in IPv6 knows that the attempt to design
>>>>extensibility
>>>> >>> into v6 failed. It won't be news to the IESG that we can't add an
>>>> >>> extension that can be processed at every hop on the fast path.
>>>> >>>
>>>> >>> If a destopt is sufficient to prove ConEx useful, then
>>>>implementers will
>>>> >>> want to satisfy this demand. Then
>>>> >>> * either there is even more pressure on the IETF to address this
>>>>failing
>>>> >>> in v6 (and maybe someone will),
>>>> >>> * or ConEx has to continue with this destopt solution, just like
>>>> >>> everyone else is finding hacks round this failing in v6.
>>>> >>>
>>>> >>> But don't ask me. Ask Suresh.
>>>> >> Yes! Unfortunately he did not response until
>>>> >> now. Maybe he is/was on holidays; will ping him again.
>>>> >>
>>>> >>
>>>> >>>>>>> Then "CDO SHOULD be first" would give no different performance
>>>>to "CDO
>>>> >>>>>>> MUST be first", if CDO actually was first. If CDO had to be
>>>>placed
>>>> >>>>>>> second on a certain packet, "CDO SHOULD be first" would take
>>>>just one
>>>> >>>>>>> more op than "CDO MUST be first".
>>>> >>>>>>>
>>>> >>>>>>> Note: I've just re-read the spec of the IPv6 header. We need to
>>>> >>>>>>> specify
>>>> >>>>>>> that CDO goes in the "Destination Options (before routing
>>>>header)",
>>>> >>>>>>> not
>>>> >>>>>>> the "Destination Options (before upper-layer header)". Then it
>>>> >>>>>>> won't be
>>>> >>>>>>> encrypted by an ESP header.
>>>> >>>>>> Thanks. I wasn't fully aware of this. But the difference for my
>>>> >>>>>> understanding is if immediate node listed in the routing header
>>>>should
>>>> >>>>>> proceed this option or not. In our case it is probably not
>>>>important
>>>> >>>>>> which one we choose as it should be processed by none of the
>>>>receivers.
>>>> >>>>> You're correct that CDO isn't processed by any of the nodes
>>>>listed in
>>>> >>>>> the routing header as destinations. The phrase "before routing
>>>>header"
>>>> >>>>> is just how its placement is described. We should clarify that this
>>>> >>>>> isn't anything to do with the processing of the routing header.
>>>> >>>>>
>>>> >>>>>> Where did you read that the later one is not encrypted though?
>>>> >>>>> ESP encrypts everything after the ESP header, and it comes just
>>>>before
>>>> >>>>> the second dest opts. So it would be no good putting CDO after it.
>>>> >>>>>
>>>> >>>>> See the ESP spec, on "ESP Header Location":
>>>> >>>>> <http://tools.ietf.org/html/rfc2406#section-3.1>
>>>> >>>>> "  The destination options extension header(s) could appear
>>>> >>>>>     either before or after the ESP header depending on the
>>>>semantics
>>>> >>>>>     desired.  However, since ESP protects only fields after the ESP
>>>> >>>>>     header, it generally may be desirable to place the destination
>>>> >>>>>     options header(s) after the ESP header.
>>>> >>>>> "
>>>> >>>> Thanks. Wasn't able to find this sentence!
>>>> >>>>
>>>> >>>>> Also see the IPv6 spec on "Extension Header Order":
>>>> >>>>> <http://tools.ietf.org/html/rfc2460#section-4.1>
>>>> >>>>>
>>>> >>>>> I believe one reason there are two places for the dest opt is
>>>>because if
>>>> >>>>> ESP is encrypting everything for the destination, it will
>>>>normally be
>>>> >>>>> expected that the dest opts need to be encrypted too. But this
>>>>wouldn't
>>>> >>>>> work if you have multiple destinations on the path in the
>>>>routing header
>>>> >>>>> (that probably don't hold the relevant key).  Fortunately, this
>>>> >>>>> exception is also needed for ConEx.
>>>> >>>>>
>>>> >>>>>> If so, I can simply add one sentence to the first paragraph of
>>>> >>>>>> section 4:
>>>> >>>>>> "The CDO MUST be placed in the destination option before routing
>>>> >>>>>> header such that it does not get encrypted and can be read by
>>>> >>>>>> immediate ConEx-aware nodes."
>>>> >>>>>> And then remove the first paragraph of the IPSec section (and
>>>>probably
>>>> >>>>>> move the other paragraph somewhere else so that the section is
>>>>removed
>>>> >>>>>> completely)...?
>>>> >>>>> I've lost track of all the proposed changes to the IPsec
>>>>section. But I
>>>> >>>>> think there is value in spelling out exactly how ConEx and IPsec
>>>> >>>>> interact, so I wouldn't remove the section completely, even if it
>>>> >>>>> repeats info elsewhere.
>>>> >>>> Okay I just realized that we recommend to to use TPSec for
>>>> >>>> authentication but I believe if the ConEx option should not be
>>>> >>>> encrypted by using the respective header, it will also not be
>>>> >>>> authenticated...? So you can have either one of the two...? I
>>>>believe
>>>> >>>> we still need the IPSec section but right now I'm not sure what to
>>>> >>>> right in there...? Any proposal?
>>>> >>> * How to do ConEx when IPsec is also required (tunnel & transport
>>>>modes,
>>>> >>> and what to count). This may all be obvious now, but (IMO) it
>>>>would still
>>>> >>> be worth spelling out obvious things.
>>>> >>> * How to use IPsec to protect the integrity of CDO.
>>>> >> Okay, this is the text now:
>>>> >>
>>>> >> "Compatibility with use of IPsec
>>>> >>
>>>> >> In IPv6 there are two possible position of a
>>>> >> Destination Option header, either before the
>>>> >> Routing header or after the Encapsulating Security Payload (ESP)
>>>>header.
>>>> >          BETTER?:
>>>> > In IPv6 a Destination Option header can be placed
>>>> > in two possible position in the order of possible
>>>> > headers, either before the Routing header or
>>>> > after the Encapsulating Security Payload (ESP) header.
>>>> >          REASONING:
>>>> > We are talking about the positions where these
>>>> > headers /would/ be if they were there - they might not actually be
>>>>present.
>>>> >
>>>> >> If the packet is encrypted using IPSec tunnel
>>>> >> mode, the CDO MUST be placed in the destination
>>>> >> option before the Routing header such that it
>>>> >> does not get encrypted and can be read by immediate ConEx-aware nodes.
>>>> >          BETTER?:
>>>> > CDO MUST always be placed in a destination option
>>>> > header placed before where the routing header
>>>> > would be. Otherwise, if CDO were placed in the
>>>> > latter position and an ESP header were used, the CDO would be
>>>>encrypt the
>>>> >          REASONING:
>>>> > (There is no need for it to ever be in the later
>>>> > position and it's best to always be in the same place.)
>>>> >
>>>> >
>>>> >> Note as the Authentication Header (AH) also only
>>>> >> protects fields after the AH header, the CDO is not authenticated
>>>>in this case.
>>>> > Need to say the encapsulator copies CDO from the
>>>> > inner IPv6 CDO before encrypting the inner.
>>>> >
>>>> > s/read by immediate/read by/
>>>> >
>>>> > AH integrity protects the IPv6 header that encapsulates it. ESP does
>>>>not.
>>>> >
>>>> >
>>>> >> In IPSec transport mode both destination option
>>>> >> headers can be used, as the CDO is in both cases
>>>> >> visible to the network. If the transport network
>>>> >> can not be trusted, the Destination Option
>>>> >> header after the ESP header SHOULD be used to
>>>> >> ensure integrity of the ConEx information. If an
>>>> >> attacker would be able to remove the ConEx
>>>> >> marks, this could        cause an audit device
>>>> >> to penalize the respective connection, while the
>>>> >> sender cannot easily detect that ConEx information is missing."
>>>> >>
>>>> >> Does this seem to be right now?
>>>> > Sorry, this is all wrong. One cannot use ESP to
>>>> > authenticate or protect the integrity of CDO by
>>>> > putting CDO after ESP, because ESP would then
>>>> > encrypt CDO so ConEx-aware nodes would not be
>>>> > able to read it. CDO always has to precede ESP,
>>>> > which is why I said CDO MUST always be in the first destopt position.
>>>> >
>>>> > If the CDO header needs to be authenticated, AH
>>>> > can be used as in the second example below. AH
>>>> > protects the integrity of the whole IPv6 datagram
>>>> > it is encapsulated by (except non-predictable
>>>> > mutable fields). AH coverage includes the IPv6
>>>> > header and extension headers before the AH
>>>> > header, and everything after the AH header too.
>>Sorry that's my fault; I thought, (similar to
>>ESP) the authentication header would only
>>authenticate headers after the AH. (Checked now with rfc4302 that I was wrong.)
>>
>>>> >
>>>> > I think it would be worth listing the two or
>>>> > three example header sequences in the draft, as
>>>> > below. Headers in [] need not be present. Headers in {} are encrypted.
>>>> >
>>>> > Transport mode without the integrity of CDO protected:
>>>> >    IPv6
>>>> >    [Hop-by-Hop]
>>>> >    [Routing]
>>>> >    Destopt(CDO[,...])
>>>> >    [Fragment]
>>>> >    ESP{
>>>> >      [Destopt]
>>>> >      Upper-Layer
>>>> >    }
>>>> >
>>>> > Transport mode with the integrity of CDO protected:
>>>> >    IPv6
>>>> >    [Hop-by-Hop]
>>>> >    [Routing]
>>>> >    Destopt(CDO[,...])
>>>> >    [Fragment]
>>>> >    AH
>>>> >    ESP{
>>>> >      [Destopt]
>>>> >      Upper-Layer
>>>> >    }
>>>> >
>>>> >
>>>> > Tunnel mode:
>>>> >    IPv6
>>>> >    [Hop-by-Hop]
>>>> >    [Routing]
>>>> >    Destopt(CDO-copy[,...])
>>>> >    [Fragment]
>>>> >    ESP{
>>>> >      IPv6
>>>> >      Destopt(CDO[,...])
>>>> >      Transport Payload
>>>> >    }
>>>> >
>>>> > For ESP in tunnel mode, as already stated in the
>>>> > draft, the tunnel ingress MUST copy the CDO from
>>>> > the destopt in the inner, then write a copy of
>>>> > the CDO header into a destopt header in the outer.
>>>> >
>>>> > I think this updates RFC2406. However, it is
>>>> > possible that 2406 already requires an ESP
>>>> > ingress to copy any extension headers, up to and
>>>> > including Fragmentation, to the outer. Because
>>>> > all these headers are designed to be visible to
>>>> > nodes on the path. Suresh may know this.
>>>
>>>I checked overnight and copying extension headers is contrary to the
>>>IPSec architecture.
>>>
>>><http://tools.ietf.org/html/rfc2401#section-5.1.2.2> "IPv6 -- Header
>>>Construction for Tunnel Mode" says:
>>>          "Extension headers  never copied"
>>>
>>>On reflection, I don't think we should update RFC2401 for ConEx. If I
>>>were on the IESG, I would not approve that. IPsec needs to have simple
>>>rules without exceptions.
>>>
>>>When we chose destopt as the mechanism for ConEx, we knew it wasn't
>>>going to interact well with tunnels. I think the best approach is to say,
>>>          "Currently, the IPv6 protocol architecture does not provide a
>>>mechanism for new extension headers to be copied to the outer. Therefore
>>>ConEx functions will have to search for the CDO option within inner
>>>headers, and ConEx will not work at all over the extent of an ESP tunnel".
>>
>>So all in all, this simplifies thing to
>>basically "CDO MUST be placed in the destination
>>option header before the AH and/or EPS (if present)."
>>
>>(+ our text just above on not interacting with tunnel mode)
>>
>>Right?
>>
>>Mirja
>>
>>>
>>>
>>>Bob
>>>
>>>
>>>> >
>>>> > To protect the integrity of the outer IPv6
>>>> > datagram, including protecting the copy of CDO,
>>>> > an AH header (not shown) could be added before ESP.
>>>> >
>>>> > [A worse alternative (no need to mention this):
>>>> > If the integrity of CDO but not other headers
>>>> > needed to be protected, ESP with authentication
>>>> > enabled could be used, which causes
>>>> > authentication data to be added at the end of the
>>>> > payload (not shown). Then, before decapsulation,
>>>> > the tunnel egress would have to record the value
>>>> > of CDO-copy. Having decrypted the inner, it could
>>>> > then check that CDO-copy matched the CDO in the
>>>> > inner.  However, that would require another
>>>> > update to RFC2406, so using AH would be
>>>> > preferable, given we don't want to make ConEx
>>>> > depend on updating both ends of an ESP tunnel - one end is bad enough.]
>>>> >
>>>> > HTH
>>>> > Sorry for taking so long - I wrote most of this
>>>> > on a plane on Thu, but left some fact checking
>>>> > for when I got online, and this is the first chance I've had to get
>>>>back to it.
>>>> >
>>>> > Cheers
>>>> >
>>>> >
>>>> >
>>>> > Bob
>>>> >
>>>> >>>>>>>>> Moreover, isn't this here the same case than with tunneling in
>>>> >>>>>>>>> general.
>>>> >>>>>>>>> Only if the node that does the encapsulation is ConEx-aware
>>>>it can
>>>> >>>>>>>>> copy
>>>> >>>>>>>>> the CDO, otherwise it will be not visible anymore.
>>>> >>>>>>>>>
>>>> >>>>>>>>> So this should either be a should, or we have to say something
>>>> >>>>>>>>> like: if
>>>> >>>>>>>>> the node is ConEx-aware is MUST copy the CDO...?
>>>> >>>>>>>> And then we can the same thing for tunneling in general...?
>>>> >>>>>>> That's surely a circular argument. What would make a tunnel
>>>>endpoint
>>>> >>>>>>> into a ConEx-aware tunnel endpoint, so that it would have to
>>>>copy the
>>>> >>>>>>> CDO? It would only become ConEx-aware if it had code added to
>>>>look for
>>>> >>>>>>> the CDO, and why would it have that code added unless it was
>>>>going
>>>> >>>>>>> to do
>>>> >>>>>>> something with CDO? That's why I think my 'MAY copy as a
>>>>performance
>>>> >>>>>>> optimisation' formula is the best we can do.
>>>> >>>>>> What you say above is the point. If the node does not know
>>>>anything
>>>> >>>>>> about ConEx, it simple cannot copy the option, which is the
>>>>case for
>>>> >>>>>> all currently existent nodes. So we cannot say MUST in general.
>>>>But if
>>>> >>>>>> the node does know that ConEx exists for any reason, it really
>>>>must
>>>> >>>>>> copy the CDO...? But you right that is a little pathologic. I'm
>>>>will
>>>> >>>>>> to change if that helps understanding/is less confusing.
>>>> >>>>> I think we're talking past each other. Given we cannot copy CDO
>>>>to the
>>>> >>>>> outer everywhere, for consistency I don't think that copying CDO
>>>>to the
>>>> >>>>> outer at all is a good idea, UNLESS it's done deliberately as
>>>>part of an
>>>> >>>>> operator's whole approach to handling ConEx. Ie. tunnel
>>>>endpoints SHOULD
>>>> >>>>> NOT copy CDO to the outer by default, but they MAY copy CDO to
>>>>the outer
>>>> >>>>> for a specific purpose (e.g. optimisation for ConEx functions
>>>>elsewhere
>>>> >>>>> in the same operator's network).
>>>> >>>> Now understood.
>>>> >>>>
>>>> >>>> I've tried to make this point a little more clear, not sure if I
>>>> >>>> succeeded:
>>>> >>>> "As with any destination option, an ingress tunnel endpoint will not
>>>> >>>> natively copy the CDO when adding an encapsulating outer IP
>>>>header. In
>>>> >>>> general an ingress tunnel SHOULD not copy the CDO to the outer
>>>>header
>>>> >>>> as this would changed the number of bytes that would be accounted.
>>>> >>>> However, it MAY copy the CDO to the outer in order to facilitate
>>>> >>>> visibility by subsequent on-path ConEx functions if the tunnel
>>>>ingree
>>>> >>>> is aware of these nodes and theses nodes are aware of the tunneling.
>>>> >>>> This trades off the performance of ConEx functions against that of
>>>> >>>> tunnel processing. "
>>>> >>> OK. Rather than implying that equipment has evolved conscious
>>>>awareness,
>>>> >>> a better formulation would be something like:
>>>> >>> "..the configuration of the tunnel ingress and the ConEx nodes is
>>>> >>> co-ordinated."
>>>> >>>
>>>> >>> Nits:
>>>> >>> s/SHOULD not/SHOULD NOT/
>>>> >>> s/accounted/counted/
>>>> >>>    (in English, accounted is not a transitive verb, it has to have
>>>>'for'
>>>> >>> after it)
>>>> >>> s/ingree/ingress/
>>>> >>> s/theses/these/
>>>> >> Done.
>>>> >>
>>>> >>
>>>> >>> We're getting there!
>>>> >> Yes...!
>>>> >>
>>>> >> Mirja
>>>> >>
>>>> >>
>>>> >>> But we really do need Suresh's expert eye on this.
>>>> >>>
>>>> >>>
>>>> >>> Cheers
>>>> >>>
>>>> >>>
>>>> >>> Bob
>>>> >>>
>>>> >>>
>>>> >>>> Mirja
>>>> >>>>
>>>> >>>>> HTH
>>>> >>>>> (Delayed 'cos it was a public holday in the UK yesterday.)
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> Bob
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>>> Bob
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>>> Mirja
>>>> >>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>>>>>> ==Security Considerations==
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> * Added lots, all pointers to where security issues are
>>>> >>>>>>>>>>>> discussed in
>>>> >>>>>>>>>>>> other places (which is what security directorate
>>>>reviewers need).
>>>> >>>>>>>>>>> Okay I can add that if you think it's necessary (I would
>>>>say it's
>>>> >>>>>>>>>>> just
>>>> >>>>>>>>>>> redundant, but you be might right that it just helps the
>>>>sec dir).
>>>> >>>>>>>>>> It's not always obvious which aspects relate to security.
>>>> >>>>>>>>>> Especially
>>>> >>>>>>>>>> when the security is structural rather than crypto. So I think
>>>> >>>>>>>>>> these
>>>> >>>>>>>>>> sentences are useful to sec dir.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>>> ==IANA==
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> * I think the act bits need to be 00 not 10 to avoid ConEx
>>>> >>>>>>>>>>>> packets
>>>> >>>>>>>>>>>> being dropped by non-ConEx nodes (including by non-ConEx
>>>> >>>>>>>>>>>> receivers)?
>>>> >>>>>>>>>>>> But I'm willing to be corrected.
>>>> >>>>>>>>>>> I agree; Will ask Suresh why he has put a 10 though.
>>>> >>>>>>>>>> Yes, he's the right guy to check with.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Bob
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>
>>>> >>>>>>>>>>> Thanks,
>>>> >>>>>>>>>>> Mirja
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Regards
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Bob
>>>> >>>>>>>>>> {Note 1}
>>>> >>>>>>>>>> For anyone watching on the list, the tentative idea that
>>>>Mirja has
>>>> >>>>>>>>>> reminded me of is documented in 11.3.1 of my PhD thesis
>>>>entitled
>>>> >>>>>>>>>> "Covert
>>>> >>>>>>>>>> Markings as a Policer Signal".
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> The potential problem: A ConEx policer punishes punishment.
>>>>If a
>>>> >>>>>>>>>> congestion policer starts dropping packets because the user
>>>>has
>>>> >>>>>>>>>> contributed excessively to congestion, in subsequent rounds
>>>>the
>>>> >>>>>>>>>> user
>>>> >>>>>>>>>> has
>>>> >>>>>>>>>> to re-echo 'L' markings for the policer drops as well. This
>>>>can
>>>> >>>>>>>>>> drive
>>>> >>>>>>>>>> the policer further into 'debit'. This might make it
>>>>difficult for
>>>> >>>>>>>>>> the
>>>> >>>>>>>>>> user to get out of trouble once she's started getting into
>>>>trouble.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> The basic idea was that when a congestion policer drops
>>>>packets
>>>> >>>>>>>>>> (because
>>>> >>>>>>>>>> the user is causing more congestion than her allowance), it
>>>>will
>>>> >>>>>>>>>> also
>>>> >>>>>>>>>> remove ConEx markings. Then (if there is some way for the
>>>> >>>>>>>>>> receiver to
>>>> >>>>>>>>>> feed this back), the sender knows not to send more ConEx marks
>>>> >>>>>>>>>> because
>>>> >>>>>>>>>> these aren't congestion drops, they are policer drops.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> We didn't that double punishment made it hard to get out of
>>>> >>>>>>>>>> trouble in
>>>> >>>>>>>>>> any policer experiments so far, so let's not allow for a
>>>>possible
>>>> >>>>>>>>>> solution to a problem that we probably don't even have. The
>>>>current
>>>> >>>>>>>>>> crop
>>>> >>>>>>>>>> of ConEx drafts are experimental anyway. If this problem does
>>>> >>>>>>>>>> surface,
>>>> >>>>>>>>>> then we can reconsider.
>>>> >>>>>>>>>>
>>>>________________________________________________________________
>>>> >>>>>>>>>> Bob
>>>>Briscoe,                                                  BT
>>>> >>>>>>>> --
>>>> >>>>>>>> ------------------------------------------
>>>> >>>>>>>> Dipl.-Ing. Mirja Kühlewind
>>>> >>>>>>>> Communication Systems Group
>>>> >>>>>>>> Institute TIK, ETH Zürich
>>>> >>>>>>>> Gloriastrasse 35, 8092 Zürich, Switzerland
>>>> >>>>>>>>
>>>> >>>>>>>> Room ETZ G93
>>>> >>>>>>>> phone: [phone]
>>>> >>>>>>>> email: [e-mail]
>>>> >>>>>>>> ------------------------------------------
>>>> >>>>>>> ________________________________________________________________
>>>> >>>>>>> Bob Briscoe,                                                  BT
>>>> >>>>>> --
>>>> >>>>>> ------------------------------------------
>>>> >>>>>> Dipl.-Ing. Mirja Kühlewind
>>>> >>>>>> Communication Systems Group
>>>> >>>>>> Institute TIK, ETH Zürich
>>>> >>>>>> Gloriastrasse 35, 8092 Zürich, Switzerland
>>>> >>>>>>
>>>> >>>>>> Room ETZ G93
>>>> >>>>>> phone: [phone]
>>>> >>>>>> email: [e-mail]
>>>> >>>>>> ------------------------------------------
>>>> >>>>> ________________________________________________________________
>>>> >>>>> Bob Briscoe,                                                  BT
>>>> >>>> --
>>>> >>>> ------------------------------------------
>>>> >>>> Dipl.-Ing. Mirja Kühlewind
>>>> >>>> Communication Systems Group
>>>> >>>> Institute TIK, ETH Zürich
>>>> >>>> Gloriastrasse 35, 8092 Zürich, Switzerland
>>>> >>>>
>>>> >>>> Room ETZ G93
>>>> >>>> phone: [phone]
>>>> >>>> email: [e-mail]
>>>> >>>> ------------------------------------------
>>>> >>> ________________________________________________________________
>>>> >>> Bob Briscoe,                                                  BT
>>>> >> --
>>>> >> ------------------------------------------
>>>> >> Dipl.-Ing. Mirja Kühlewind
>>>> >> Communication Systems Group
>>>> >> Institute TIK, ETH Zürich
>>>> >> Gloriastrasse 35, 8092 Zürich, Switzerland
>>>> >>
>>>> >> Room ETZ G93
>>>> >> phone: [phone]
>>>> >> email: [e-mail]
>>>> >> ------------------------------------------
>>>> > ________________________________________________________________
>>>> > Bob Briscoe,                                                  BT
>>>> >
>>>> >
>>>
>>>________________________________________________________________
>>>Bob Briscoe,                                                  BT
>>
>>--
>>------------------------------------------
>>Dipl.-Ing. Mirja Kühlewind
>>Communication Systems Group
>>Institute TIK, ETH Zürich
>>Gloriastrasse 35, 8092 Zürich, Switzerland
>>
>>Room ETZ G93
>>phone: [phone]
>>email: [e-mail]
>>------------------------------------------
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: [phone]
email: [e-mail]
------------------------------------------