Subject: Re: shim6-proto-07 review
From: marcelo bagnulo braun <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: shim6-wg <[email-masked]>
Date: Thu, 28 Dec 2006 18:58:01 +0100

Hi Iljitsch,

sorry for the delay and thank you for the review...

I have sent a separate reply to the most substantial issues. for the 
remaining issues (which are many and not all of them editorial), i 
comment below...

El 11/12/2006, a las 19:54, Iljitsch van Beijnum escribió:

> (Note that I'm behind on the shim6 list so I'm not aware of recently 
> discussed issues, so these may be duplicated here.)
>
> This is a review of the shim proto 07 draft. It contains both nits and 
> more fundamental issues, they are presented in the order of the text, 
> but let me get two other things out of the way first:
>
> 1. Always including the context tag
>

sent a separate email for this

>
> 2. Congestion
>
> There is no discussion of congestion issues when the shim moves 
> ongoing communicaiton to another locator pair, which will generally 
> make the communication flow over a different path. We've had some 
> discussions about this before, where the suggestion was made to go 
> into slow start after a rehoming event. The counter argument: but 
> maybe the new path is just as fast as the old one. My counter counter 
> argument: suppose a file transfer over a 1 Gbps link, the Gbps link 
> goes down and the session is rehomed to a low speed link (GPRS, modem, 
> ADSL with limited uplink capacity). The send window used when the 
> session went along over the Gbps link will be so large that massive 
> congestion ensues, and also, all buffers will be filled up which 
> guarantuees that the congestion will persist for a relatively long 
> time, possibly a handful of seconds.
>
> There are no easy answers here, but congestion control is one of the 
> core concerns in the development of the internet, so I don't think we 
> can get away with ignoring this completely.
>

i can see this is an issue...

what do you suggest to do here? could you send text?

>
>    o  Preserve established communications in the presence of certain
>       classes of failures, for example, TCP connections and UDP 
> streams.
>
> Shouldn't this be "communication"?

i don't think so...

it could be Preserve an established communication or Preserve 
established communications

i think it is better the second one, because the first option seems we 
are talking about a given specific communication...

>
>
>    o  Have minimal impact on upper layer protocols in general and on
>       transport protocols in particular.
>
> And applications.

ok

>
>
> Early in the text, the phrase "site multihoming" is used. There has 
> been some discussion on this list as to whether shim6 actually is site 
> multihoming, and readers of the draft may not know that all of this is 
> the result of wgs chartered to work on "site" multihoming. So I 
> suggest adding text to clear up any potential confusion, for example:
>
> "The shim protocol is a site multihoming solution in the sense that it 
> allows existing communication to continue when a site that has 
> multiple connections to the internet experiences an outage on a subset 
> of these connections or further upstream. However, shim processing is 
> performed in individual hosts rather than through site-wide 
> mechanisms."

ok will add this... did you have a place in the draft you were thinking 
for this text?

>
>
>    Finally, this proposal also does not try to provide a new network
>    level or transport level identifier name space distinct from the
>    current IP address name space.
>
> The terms "identifier" and "locator" are used extensively even though 
> the shim is NOT an actual identifier/locator separation solution... 
> Suggested text (immediately following the sentence above):
>
> "The shim proposal doesn't fully separate the identifier and locator 
> functions that have traditionally been overloaded in the IP address. 
> However, throughout this document the term "identifier", or more 
> specifically, Upper Layer Identifier (ULID) refers to the identifying 
> function of an IPv6 address, and "locator" to the network layer 
> routing and forwarding properties of an IPv6 address."
>

ok will add that

>
>    solution.  While this document doesn't specify all aspects of this,
>    it is believed that the approach can be extended to handle the non-
>    routable address case..
>
> Extra period.

ok

> (Note that the quaint custom of inserting an extra space after a 
> sentence is generally "discouraged" in style manuals.)
>

it is only after each paragraph, not after each sentence afaict

>
>    the original locators become invalid at the same time and depending
>    on the time that is required to update the DNS and for those updates
>    to propagate.
>
> Why is the DNS relevant here?
>
>

because at least one valid locator must be published in the DNS in 
order for a shim host to be reachable, since the DNS is used as a 
rendez vous mechanism. OTOH, this is no specific of the shim6 protocol, 
but generic for any host... do you prefer we remove the DNS 
consideration from here?

>    But IP addresses are also used as ULID,
>
> Addresses is plural, ULID singular... Probably make this "ULIDs".
>

ok

>
>    In the worst case we could end up with two separate hosts using the
>    same ULID while both of them are communicating with the same host.
>
>    This potential source for confusion is avoided requiring that any
>    communication using a ULID MUST be terminated when the ULID becomes
>    invalid (due to the underlying prefix becoming invalid).
>
> This makes me uncomfortable. How do you know that an address has 
> become terminally invalid, rather than accidentally unusable?
>

this was discussed during the last meeting in san diego and there was 
consensus that if a prefix is removed from the site, existing shim 
contexts that are using a ulid containing the prefix must be terminated 
when the prefix is removed.
however, i read from your comment is that you don't have a problem with 
this idea but your problem is with how to implement this, right?

>  I contend that the distinction can't be made in a stack in a 
> meaningful way,

what about when the address becomes invalid?

>  so the above requirement will in practice only serve to disrupt 
> communication unnecessary. Rather, I would require some administrative 
> "cooling off" period to avoid using the same ULID by a different host 
> (only possible with CGA not HBA anyway). For instance, there must be 
> 24 hours between decommisioning and recommisioning of address space, 
> and we garbage collect shim state after 24 hours of not being used.
>

but what do you mean the decomisioning of the prefix? wouldn't be this 
the time the prefix is removed from the site? if this is so, the 
current draft recommends that the existing shim6 contexts that are 
using ulids containing this prefix are terminated

in other words, i fail to see why this is easier to implement that what 
is currently in the draft. I mean, if the admin can determine the 
decomisioning time, it also can terminate the existing shim6 
contexts...

> I don't see how regular nomadic behavior will result in two hosts 
> using the same address in quick succession, and they can further 
> reduce the potential for problems by not using temporary addresses as 
> ULIDs.
>

i am not sure what part of the draft this comment is referred to, but 
if a nomadic host creates a ulid using a temporary prefix and it moves 
away and then another nomadic hosts attaches itself to the same network 
and generates the same address, it is possible that the the two nomadic 
hosts end up using the same address. Now, it is worse a ULID collision 
than a locator collision, in particular, beacause once the first 
nomadic hosts leaves the visited network, the locator becomes 
unreachable, so it cannot longer be used, even if the hosts wants to 
use it. OTOH, if the address is being used as ulid, the first nomadic 
host can keep on using it, even if it is no longer located in the 
network from which it obtained the address. so i guess the comment 
makes sense to me.

>
>    layer map to/from different locators.  The shim6 layer maintains
>    state, called ULID-pair context, per ULID pairs
>
> "Pairs" should probably be singular.
>

ok

>
>    fields, and even though those locators may be changed by the
>    transmitting shim6 layer. .
>
> Extra  .
>

ok

>    The result of this consistent mapping is that there is no impact on
>    the ULPs.  In particular, there is no impact on pseudo-header
>    checksums and connection identification.
>
>
> The problem here is that some intermediate system, such as a firewall 
> or a smart NIC, may take it upon itself to check the TCP or UDP 
> checksum and discard the packet if the checksum fails.

comments in a separate email

>
>
>    Inherent in a scalable multihoming mechanism that separates locators
>    from identifiers is that each host ends up with multiple locators.
>
> This says explicitly that we do id/loc...
>

yes i can rephrase it using the id locator function terminology that 
you suggested previously

>
>    This means that at least for initial contact, it is the remote peer
>    that needs to select which peer locator to try first.  In the case 
> of
>    shim6 this is performed by applying RFC 3484 address selection.
>
> This is incorrect: the application (or layer working on its behalf) 
> needs to select an initial ULID, which automatically becomes the 
> initial locator.

agree, will rephrase this

>
>
>    This document uses the terms MUST, SHOULD, RECOMMENDED, MAY, SHOULD
>    NOT and MUST NOT defined in RFC 2119 [1].  The terms defined in RFC
>    2460 [2] are also used.
>
> Please list them.

ok, will try

>
>
>    FQDN                Fully Qualified Domain Name
>
> Hm, if you don't know what FQDN is you probably also don't know what 
> it is when spelled out... How about adding "full DNS name"?
>

i guess the goal here is just to describe the acronym, not to provide a 
definition

>
>    document), such as having the ISPs relax there ingress filters, or
>    selecting the egress such that it matches the IP source address
>    prefix.
>
> There -> their
>

ok

>
>    o  Some heuristic on A or B (or both) determine that it is
>       appropriate to pay the shim6 overhead to make this host-to-host
>       communication robust against locator failures.  For instance, 
> this
>       heuristic might be that more than 50 packets have been sent or
>       received, or a timer expiration while active packet exchange is 
> in
>       place.  This makes the shim initiate the 4-way context
>       establishment exchange.
>
> Maybe say something like:
>
> "The purpose of this heuristic is to avoid setting up a shim context 
> when only a small number of packets is exchanged between two hosts."
>

ok, will add this

>
>       If the context establishment exchange fails, the initiator will
>       then know that the other end does not support shim6, and will
>       continue with standard unicast behavior for the session.
>
> Unicast? Shouldn't this be "single homed"?
>

will change to standard (non-shim6) behaviour, ok?

>
>    the message allocated.  Thus at a minimum the combination of <peer
>    ULID, local ULID, local context tag> have to uniquely identify one
>    context.
>
> I'm not sure if I understand this.
>
> More in general, the draft seems to suggest that the content of the 
> source address field in received packets may be ignored,

this is explicitly stated in the draft

actually the complete paragraph from where the sentence above belongs 
to states:

       A context between two hosts is actually a context between two 
ULIDs.
    The context is identified by a pair of context tags.  Each end gets
    to allocate a context tag, and once the context is established, most
    shim6 control messages contain the context tag that the receiver of
    the message allocated.  Thus at a minimum the combination of <peer
    ULID, local ULID, local context tag> have to uniquely identify one
    context.  But since the Payload extension headers are demultiplexed
    without looking at the locators in the packet, the receiver will need
    to allocate context tags that are unique for all its contexts.  The
    context tag is a 47-bit number (the largest which can fit in an
    8-octet extension header).

as you can see, it is explicitly mentioned that the locators in the 
packet are not used for demux and this is the assumption that is used 
over the whole draft

actually, the first sentence of this paragraph where the uniqueness of 
peer ulid, local ulid and context tag is required, is only included for 
provide the context in which the design was performed. The actual 
design choice that was made was that context tags are unique in a host.

have you identified other places of the draft where it is mentioned 
that the demux is performed taking into account the locators in 
addition of the context tag?

>  but also that this is not the case. This is a very important decision 
> with far reaching consequences so it should be made carefully. For 
> instance, if the source address may be rewritten arbitrarily, 
> obviously routers can easily do this without much or any coordination. 
> But the potential for security issues is significant in this case.
>

the security level provided by the shim6 protocol relies on the context 
tag. Any attacker needs to learn the context tag before being able to 
inject addresses into an established context. It was concluded that 
this is an acceptable security level and similar to the one available 
in today's internet... do you agree?
>
>    context.  But since the Payload extension headers are demultiplexed
>    without looking at the locators in the packet, the receiver will 
> need
>    to allocate context tags that are unique for all its contexts.
>
> See above.
>
>
>    context tag is a 47-bit number (the largest which can fit in an
>    8-octet extension header).
>
> "while preserving one bit to differentiate the shim signalling 
> messages from the shim header included in data packets, allowing both 
> to use the same protocol number."

ok

>
>
> 4.2 context forking
>
> Never been a fan of this, but it doesn't seem to add too much extra 
> complexity the way it is now.
>

fair enough...

>
>       Such discovery probably requires to be along the path in order to
>       be sniff the context tag value.
>
> Grammar: clause without subject. Who is required to be along the path?
>

will rephrase

>
>    dynamic.  For this reason there is a Update Request and Update
>    Acknowledgement messages, and a Locator List option.
>
> Grammar. "is a" -> "are" would be better.
>

ok

>
>    Even when the list of locators is fixed, a host might determine that
>    some preferences might have changed.  For instance, it might
>    determine that there is a locally visible failure that implies that
>    some locator(s) are no longer usable.  This uses a Locator
>    Preferences option in the Update Request message.
>
> I don't consider reachability status a preference...
>

the flags in the locator preference options, in particular the broken 
flag is used for this.  I may agree that this is not a preference, but 
the other information which is related to this is preference and this 
flag needed to be included somewhere and this seems the natural 
place...

>
>    Bidirectional Communication (FBD).  FBD uses a Keepalive message
>    which is sent when a host has received packets from its peer but has
>    not yet sent any packets from its ULP to the peer.
>
> No, this works per address (per locator even, not per ULID, IIRC), not 
> per ULP.
>

the meaning here is that FBD generates packets when the ULPs are 
silent. It doesn't mean that it generates packets per ULP, just that 
when all ULPs are silent, FBD generates packets. It may be rephrased as 
follows:

    FBD uses a Keepalive message
    which is sent when a host has received packets from its peer but has
    not yet sent any packets from any of its ULPs to the peer.

would this be better?

>
>    which precedes a routing header).  When tunneling is used, whether
>    IP-in-IP tunneling or the special form of tunneling that Mobile IPv6
>    uses (with Home Address Options and Routing header type 2), there is
>    a choice whether the shim applies inside the tunnel or outside the
>    tunnel, which affects the location of the shim6 header.
>
> How is this coordinated with the other side? If one side does 
> tunneling first and shim second and the other side the other way 
> around, there will be trouble. I don't see an easy way to avoid this.
>

the header order would be enough imho. I mean, when tunneling is 
performed, two IP layers are involved and each ip layer can have its 
own shim sublayer inside. So, for each ip layer a shim header can be 
added, so depending on the location of the shim header, how it applies, 
makes sense?

>
>    the control messages; only the payload extension header use the Next
>    Header field.
>
> uses
>
ok

>
>    Next Header:   8-bit selector.  Normally set to NO_NXT_HDR (59).
>
> So what happens when some other header follows the shim header? Could 
> this be used for attacks?
>

this is for shim6 control messages and so far we haven't defined means 
to perform piggybacking of other protocols in shim6 control messages, 
so it is not possible for other protocols to follow the shim header. If 
this is defined in future extensions, they will need to update this 
part of the spec

>
> About the different messages: they are very similar. If I were to 
> implement all of this, I would rather work with one basic structure 
> for all of the messages, even if the _meaning_ of some fields is 
> different as long as their structure is always the same. I think this 
> can easily be done here, by including fields that nearly all messages 
> need (simply leave it zero when a particular message doesn't need a 
> field) and use options for things that a particular message needs that 
> aren't accommodated in the unified structure.
>

i can clearly see the cost of this approach, additional overhead for 
unused fields and potential source of confusion when fields change 
their name... what is the advantage of such approach?

> Did I miss the place where HBA information is exchanged?
>

The CGA Parameter data structure option contains all the information 
required by the HBA

> update request: why is this a request?
>

because this is a two way protocol, update and request... (i do agree 
that it is not the best name in this case... suggestion?)

>
>    This message is sent in response to a Update Request message.  It
>    implies that the Update Request has been received, and that any new
>    locators in the Update Request can now be used as the source 
> locators
>    of packets.  But it does not imply that the (new) locators have been
>    verified to be used as a destination, since the host might defer the
>    verification of a locator until it sees a need to use a locator as
>    the destination.
>
> Hm, is it smart to defer verification here?

depending what verification we are talking about....

this is explained in detail in section 7.2.  Locator Verification

there are two type of verification HBA/CGA verification is one type and 
the other type is the one against flooding attakcs that is achived 
using a probe packets (of the path exploration protocol)

The spec in section 7.2 states that:

    Thus the HBA/CGA
    verification SHOULD be performed by the host before the host
    acknowledges the new locator, by sending an Update Acknowledgement
    message, or an R2 message.

    Before a host can use a locator (different than the ULID) as the
    destination locator it MUST perform the HBA/CGA verification if this
    was not performed before upon the reception of the locator set.  In
    addition, it MUST verify that the ULID is indeed present at that
    locator.  This verification is performed by doing a return-
    routability test as part of the Probe sub-protocol [9].

makes sense?

>  We've already said that the other end may use them as source 
> addresses. If there is a failure and we do the verification then, we 
> may find out that it fails and we have no reasonable course of action.
>
> Also, for CGA verification, don't we need to send the other side a 
> challenge to avoid replays?
>

separate email for this issue

>
>    direction.  When the ULP is sending bidirectional traffic, no extra
>    packets need to be inserted.
>
> This works per address pair, not per ULP.
>

this is similar to what we were discussing above...

the ulps are the one sending traffic... maybe we can rephrase it as:

When the traffic generated by the ULPs results in a bidirectional flow 
of packet between the peers, no extra packets need to be inserted.

is this ok?
>
> 5.13.  Probe Message Format
>
>    This message and its semantics are defined in [9].
>
>    The idea behind that mechanism is to be able to handle the case when
>    one locator pair works in from A to B, and another locator pair 
> works
>    from B to A, but there is no locator pair which works in both
>    directions.  The protocol mechanism is that as A is sending probe
>    messages to B, B will observe which locator pairs it has received
>    from and report that back in probe messages it is sending to A.
>
> No, this is to test whether locator pairs work or not in the general 
> case.
>

agree, we went on describing the details without previously describing 
the main idea...

we can add your sentence at the begining of the paragraph, resulting in:

    The goal of this mechanism is to test whether locator pairs work or
    not in the general case. In particular, this mechanism is able to 
handle the case when
    one locator pair works in from A to B, and another locator pair works
    from B to A, but there is no locator pair which works in both
    directions.  The protocol mechanism is that as A is sending probe
    messages to B, B will observe which locator pairs it has received
    from and report that back in probe messages it is sending to A.

would this be ok?

>
>    All of the TLV parameters have a length (including Type and Length
>    fields) which is a multiple of 8 bytes.
>
> Ugh, this is certainly enough to make a grown man cry... Why all of 
> this alignment silliness? BGP works pretty well without it.
>

i think this is general in IPv6 protocols which are optimized for 
handling 64 bits units.... but maybe someone with more expertise can 
answer this one...

>
>    Consequently, the Length field indicates the length of the Contents
>    field (in bytes).  The total length of the TLV parameter (including
>    Type, Length, Contents, and Padding) is related to the Length field
>    according to the following formula:
>
>    Total Length = 11 + Length - (Length + 3) % 8;
>
> This is almost impossible to understand.
>
> First of all, this assumes familiarity with C or a similar language 
> from the reader to note that % is the modulo operation and that it 
> binds stronger than subtraction. As such, this would be an 
> improvement:
>
> Total Length = 11 + Length - ((Length + 3) mod 8)
>

ok

> However, the logic that underpins this is never spelled out, apart 
> from the requirement that all options be a multiple of 8 bytes long. 
> (Yes, _bytes_, not octets.)
>
> Text:
>
> "The Total Length of the option is the smallest multiple of 8 bytes 
> that allows for the 4 bytes of option header and the option itself. 
> The amount of padding required can be calculated as follows:
>
> padding = 7 - ((Length + 3) mod 8)
>
> And:
>
> Total Length = 4 + Length + padding"
>
>

great, thanks!!

will add this

> I see no discussion of size issues. A single option can be made large 
> enough to push a packet beyond 1280 bytes. More realistically, this 
> will happen when multiple options are present. What happens in this 
> case? What is the largest option size and the largest shim packet size 
> implementations must be prepared to handle?
>

separate email for this

>

>    C:             Critical.  One if this parameter is critical, and 
> MUST
>                   be recognized by the recipient, zero otherwise.
>
> You can't force a receiver to recognize something...
>

in general, i think this means that if this bit is set and the receiver 
don't understand the content, then it must react accordingly. If not 
critical, it simply silently ignore the option

i can rephrase it to express this....

>
>    o  If C=1 then the host SHOULD send back an ICMP parameter problem
>       (type 4, code 1), with the Pointer referencing the first octet in
>       the option Type field.  When C=1 the message MUST NOT be
>       processed.
>
> Why use ICMP for errors? Isn't it easier to define a shim error 
> message?
>  If the correspondent wants to fall back to some other way to set up 
> the shim having to intercept ICMP messages to make that happen is 
> pretty messy.
>
> More in general, most error conditions are handled by silently 
> dropping packets, however, which is a very bad idea because that way, 
> there is no difference between an error and lost messages.
>  So in some cases, a host may continue to resend the offending packet 
> because it doesn't know something went wrong. The main problem with 
> this approach is that you can't debug it from one end: you need to see 
> what happens on both ends to determine why something doesn't work.
>
> Silently dropping packets because of errors is the right approach for 
> security reasons in some cases, but I don't think this applies here. A 
> short error message with an error code and optionally a human-readable 
> message would be much better. As long as these error packets are 
> smaller than the packets that trigger them, there should be little or 
> no security impact, especially considering that we're prepared to talk 
> shim with the correspondent in question to begin with.
>

sent this issue in a separate email

>
>    The responder can choose exactly what input is used to compute the
>    validator, and what one-way function (MD5, SHA1)
>
> Or something else, I presume? So "(such as MD5 or SHA-1)"
>

ok

>
> About the locator option: how many locators are allowed?
>

there is no upper limit other than the ones that fit inside a packet 
with the other required options... As i mentioned above, roughly this 
seemed enough not to become a limitation

>
>       TEMPORARY: 0x02
>
>    The intent of the BROKEN flag is to inform the peer that a given
>    locator is known to be not working.  The intent of TEMPORARY is to
>    allow the distinction between more stable addresses and less stable
>    addresses when shim6 is combined with IP mobility, when we might 
> have
>    more stable home locators, and less stable care-of-locators.
>
> So this has nothing to do with RFC 3041 temporary addresses?

right

> In that case, a different name is probably better.
>

agree... what about "transient"?

>
>    o  For each peer locator, a bit whether it has been verified using
>       HBA or CGA, and a bit whether the locator has been probed to
>       verify that the ULID is present at that location.
>
> "Flag" rather than "bit"?

no preference here, so flag if you find it clearer

>
>
>    | E-FAILED            | Context establishment exchange failed
>
> How do we know this,

becuase we have retried several times with I1 and never got a R1 back

>  and is it necessary to explicitly take notice of this situation?

yes, so we don't try again for a while

makes sense?

>
>
>    | E-FAILED            | ULID(peer), ULID(local)                     
> |
>    |                     |                                             
> |
>    | NO-SUPPORT          | ULID(peer), ULID(local)
>
> How is ULID(local) relevant here?

because we have tried to establish a shim6 context for a given ULID 
pair.

>  We know there is connectivity (ULP is running)

this is not necesarily the case, we can try to establish the shim6 
context without having an ongoing ulp communication

>  so if we don't get any shim negotation back or it fails, then this 
> situation can be attributed to the peer as a whole, not to the ULID 
> pair.

agree, but you don't know what are all the ULIDs of the peer, so i 
guess that at this point, caching that a shim6 context establishment 
exchange has failed for this ULID pair is the best you can do at this 
point...
>
>
>    In all the cases the result is that the peer without state receives 
> a
>    shim message for which it has to context for the context tag.
>
> To -> no?

ok

>
>
>    case we can not use the recovery mechanisms since there needs to be
>    separate context tags for the two ULID pairs.
>
> Needs -> need
>

ok

>
> Regarding section 7.9: shouldn't there be checks to make sure that 
> seemingly duplicate packets contain the same information as the 
> earlier packets they are supposedly the duplicate of?
>

I am not following you here...

are we talking about an initiator that receives a duplicate R1 back or 
a receiver that receives a duplicate I1?

If a receiver receives a duplicate I1 it doesn't do anything special, 
just replies with a R1. don't see any problem here

If an initiator receives a duplicated R1 (this may be due that the 
initiator have retried with multiple I1), it will process the first one 
received, and send a I2. The second one received, there will be no 
shim6 context in I1-SENT state, so it will be discarded. I do not see 
the point in verifying that the other information in the packet is ok 
or not... what would be the point in doing this verification?

> What if validators don't match? Eventually this shouldn't be a problem 
> but I expect some initial trouble here because you're doing hashes 
> over a fairly large number of values, a small mistake somewhere means 
> the hash doesn't work, some feedback in the form of an error message 
> would be good.

you mean for the first packet or for the following (duplicated)  
packets? for the first packet, this is a specific case of the general 
problem about whether it is ok to silently discard wrong packets (that 
i have initiated a new thread for this)
For the second case, i don't see any point on doing this...

>
>
> It occurs to me that there is nothing or very little in the protocol 
> that precludes shim negotiation using non-ULID addresses.

not sure what you mean by non ulid addresses....

>  We probably need a few minor tweaks to the reachability protocol to 
> also allow this, but then there is no fundamental reason to not allow 
> shim setup using non-ULID addresses, and by extension, unreachable 
> ULIDs = a separate identifier space.

if you mean that the shim protocol can support unreachable ULIDs like 
ULAs, then the answer is yes, it has been taken into account and should 
work fine with unreachable ulids...(you cannot do deferred setup but 
the spec supports it)

>  If it's this easy, we should definately make sure there isn't some 
> minor obstacle somewhere,

this has been done, and i hope there are no obstacles. If you have 
identified some, please let me know

>  so that we can add this feature easily in the future when we've 
> worked out the additional issues such as locator discovery.
>
>
>
>    o  Where Ls(peer) has at least one locator in common with the newly
>       created or updated context.
>
> Why? I don't see how that buys us anything. Also, it's fairly trivial 
> to insert a bogus locator to meet the requirement that there is one in 
> common between the old and new sets.
>

this is not a security check. The goal of this verification is to find 
out whether we are in the context confusion situation i.e. if we have a 
single peer that is using the same context tag value for two different 
contexts. We can identify this situation because of the overlapping of 
at least one locator in the locator set (this means it is the same host 
in both contexts)

> Adn why verify whether the source address is in Ls(peer)? The security 
> mechanisms do all the checking we need.
>

could you point me where is the text you are referring to? i mean there 
is no such verification in section 7.15 which was the section the 
previous comment was referring to...

>
>       context.  In this case, we are in the Context confusion 
> situation,
>       and the host MUST NOT use the old context to send any packets.  
> It
>       MAY just discard the old context (after all, the peer has
>       discarded it), or it MAY attempt to re-establish the old context
>       by sending a new I1 message and moving its state to I1-SENT.  In
>       any case, once that this situation is detected, the host MUST NOT
>       keep two contexts with overlapping Ls(peer) locator sets and the
>       same context tag in ESTABLISHED state, since this would result in
>       demultiplexing problems on the peer.
>
> What if an attacker is trying to interfere with legitimate 
> communication? We must be VERY sure that the new shim messages come 
> from the same host as the one that created the existing state if we're 
> going to mess with that existing state.
>

separate email for this

>

> About the randomness of the context tag: I don't think we have to 
> require that the entire context tag random in a cryptographically 
> strong sense. If this makes implementation easier, why not allow an 
> implementation to use part of the CT to be used as a lookup key (which 
> is relatively easy to predict) as long as enough bits are really 
> random? In my opinion, 20 good random bits is enough here. Suggested 
> text (but no suggested place to put it):
>
> "It is important that context tags are hard to guess for off-path 
> attackers. Therefore, if an implementation uses structure in the 
> context tag to facilitate efficient lookups, at least 20 bits of the 
> context tag must be unstructured and populated by completely random 
> bits. For this purpose, bits derived from one of the generally used 
> one-way hash functions such as SHA-1 may be considered random.

yes, structure in context tags can be useful for other purposes as 
well, so i think your recomendation is ok

>
>
>    A host MUST silently discard any received Update Acknowledgement
>    messages that do not satisfy all of the following validity checks in
>    addition to those specified in Section 12.2:
>
>    o  The Hdr Ext Len field is at least 1, i.e., the length is at least
>       16 octets.
>
> Added bonus when the header structure is unified: no need to repeat 
> the above over and over throughout the text.
>
>
>    NO_R1_HOLDDOWN_TIME = 1 min
>
>    ICMP_HOLDDOWN_TIME = 10 min
>
> This seems rather short, basically a shim host talking to a non-shim 
> host would retry setting up the shim every minute or every 10 minutes 
> even though there is good reason to assume this won't be successful. 
> Something like several hours seems more appropriate. (And only when 
> packets are actively exchanged.)
>

well, NO_R1_HOLDDOWN_TIME is about how long we should wait until we 
retry when no R1 have been received. Note that this may be due to 
network outages that can be solved in a short time. So, we have a good 
reason to assume this will be successful, someone fixed the network 
path :-)

in the other case, i agree, what about:

    NO_R1_HOLDDOWN_TIME = 5 min

    ICMP_HOLDDOWN_TIME = 60 min

>
>    network transit path.  Second, in case that IPSec is implemented as
>    Bump-In-The-Wire (BITW) [7] it is expected that the shim6 sub-layer
>    is also implemnted in the same fashion.
>
> Not strong enough:
>
> "in case that IPSec is implemented as Bump-In-The-Wire (BITW) [7], 
> either the shim MUST be disabled, or the shim MUST also be implemented 
> as Bump-In-The-Wire, in order to satisfy the requirement that IPsec is 
> layered above the shim."
>

ok

>
>       could require a 2-way handshake "did you really loose the state?"
>       in response to the error message.
>
> lose
>

ok

>
>    o  The validator included in the R1 and R1bis packets are generated
>       as a hash of several input parameters.  However, most of the
>       inputs are actually determined by the sender, and only the secret
>       value S is unknown to the sender.  However, the resulting
>       protection is deemed to be enough since it would be easier for 
> the
>       attacker to just obtain a new validator sending a I1 packet than
>       performing all the computations required to determine the secret
>       S. However, it is recommended that the host changes the secret S
>       periodically.
>
> Too many howevers...
>

will try to rephrase

>
>    o  Study whether a host explicitly fail communication when a ULID
>       becomes invalid (based on RFC 2462 lifetimes or DHCPv6), or 
> should
>       we let the communication continue using the invalidated ULID (it
>       can certainly work since other locators will be used).
>
> Some kind of grammar problem, not obvious to me what is meant here.
>

we have discussed this problem and already agreed on terminating the 
communication, so i will remove this paragrpah

>
> Appendix B.  Simplified State Machine
>
>    The states are defined in Section 6.2.  The intent is that the
>    stylized description below be consistent with the textual 
> description
>    in the specification, but should they conflict, the textual
>    description is normative.
>
> Haven't looked at this.
>
>
>    that the Flow Label carries context information as proposed in the
>    now expired NOID draft. .
>
> Extra  .

ok

>
>
>    It may happen, that later on, one of the hosts, e.g.  Host A looses
>    the shim context.
>
> loses
>

ok

>
>    Mechanisms for detecting context. loss
>
> Extra word?
>
>

    Mechanisms for detecting context loss.

:-)

> There are discussions in the appendixes, maybe make this a separate 
> document?
>

i am ok either way....

>
> The Locator List Option Format only specifies two verification methods 
> at this time: CGA or HBA. What about the case where a locator can be 
> verified using either CGA or HBA? Maybe it makes more sense to have 
> each method be a bit so they can be present or absent independently.
>

if this turns to be useful we could define a verification code that 
would be CGA or HBA but i don't see why this would be useful... do you?

>
>    approach eliminates the possibility of a context confusion situation
>    because premature garbage collection, but it does not prevents
>
> prevent
>
ok

>
>    [9]  Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
>         Exploration Protocol for IPv6  Multihoming",
>
> Please make this "I. van Beijnum"
>

will try if the xml tool allows me to....

>
> Note to self: look at implications of the fact that keepalive and 
> probe messages (as defined here) don't trigger R1bis in the 
> reachability draft.
>

Delivery-date: Thu, 28 Dec 2006 17:59:42 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: length of shim6 control mesages
Date: Thu, 28 Dec 2006 18:57:56 +0100
To: Iljitsch van Beijnum <[email-masked]>

Iljitsch in his review has raised the following issue:

my comments are inline

> I see no discussion of size issues. A single option can be made large 
> enough to push a packet beyond 1280 bytes. More realistically, this 
> will happen when multiple options are present. What happens in this 
> case? What is the largest option size and the largest shim packet size 
> implementations must be prepared to handle?
>

so far we haven't considered the case where the options wouldn't fit in 
one packet... 1280 bytes seems big enough.... otoh, CGA parameter data 
strutucture may be quite big, but not much more than 3000 bits, and i 
guess that in general there won't be much more than 10 addresses in a 
locator set, which is 1280 bits more.... so we are still with quite a 
few extra bits...
In addition, it is always possible to do option engineering, meaning 
that in the case that you need to send many options, you can send them 
in different messages. In particular, you need to send the CGA paramter 
data strucutre only once, and then you can send the other options in 
UPDATe messages...

the other option would be to define a mechanism to fragment shim6 
control messages, but i think this i too much complexity for this, that 
seems to be a corner case...

what do you suggest?

Delivery-date: Thu, 28 Dec 2006 17:59:15 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: always including the context tag
Date: Thu, 28 Dec 2006 18:57:45 +0100
To: Iljitsch van Beijnum <[email-masked]>

In his review Iljitsch raises the following issue:

my comments are online:

please comment on the issue related to if we should support other 
mechanisms for demux other than the context tag contained in the shim 
payload header

> 1. Always including the context tag
>
> As I've said many times, it's a very bad idea to unnecessarily 
> increase overhead.

well, i think having an additional header is the clean way to do this, 
because there is an additional layer that is being inserted and the 
layer needs to perform its signalling and this is achieved using a 
extra header.

>  Not only is this a bad thing in and of itself, but it also doesn't 
> help convince people to forego IPv4+BGP in favor of IPv6+shim.
>
> Now if we only include the shim header containing the context tag 
> after a failure, this could be a reasonable tradeoff. However, I'm 
> quite sure that if and when shim6 is adopted, some people will use it 
> to manage their traffic engineering by doing a locator change 
> immediately and proceed in a shimmed state for the rest of the 
> communication session.
>
> Earlier, I proposed to include a mandatory way for a host to instruct 
> its peer to not include the shim header, pending mechanisms to do 
> demultiplexing without the context tag. After reading the draft, I 
> realize that this imposes some extra ICMP demultiplexing difficulties 
> on implementations.

depending on which fields do you use for the demux, i guess... i mean 
if you use the flow label, there wouldn't be additional problems, i 
think, right?

>  So if the wg doesn't want to include this mandatory option, I suggest 
> something different: since the traffic engineering mechanisms aren't 
> really developed anyway and this problem is related to that, simply 
> remove the locator preferences mechanism so that the context tag 
> suppression can be included when proper traffic engineering is added.
>

i don't think this is such a good idea...

i mean i think locator preferneces are useful, i don't see why we 
should remove them from the spec...

> Also see draft-van-beijnum-shim6-suppress-header-00.txt (do it while 
> you can, it expires next week...), this outlines a more fully formed 
> mechanism to suppress the context tag header.
>
> I would very much like to see a consensus call on this subject.
>
> 	

Delivery-date: Thu, 28 Dec 2006 17:59:12 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: about the ULID in the TCP checksum
Date: Thu, 28 Dec 2006 18:57:51 +0100
To: Iljitsch van Beijnum <[email-masked]>

Iljitsch in his review raises the following issue:

my comments are inline

>    The result of this consistent mapping is that there is no impact on
>    the ULPs.  In particular, there is no impact on pseudo-header
>    checksums and connection identification.
>
>
> The problem here is that some intermediate system, such as a firewall 
> or a smart NIC, may take it upon itself to check the TCP or UDP 
> checksum and discard the packet if the checksum fails.

how common is this practice? is this widely used?

>  For firewalls and the like, the best thing is probably either to 
> fully monitor the shim state so they can do this properly, or forego 
> such checking if a shim header is present.
>

yes, this is probably useful in terms of security also, just like in 
the case to TCP connections, where the firewall can decide to accept 
segments of connections for which the firewall have previosuly seen SYN 
exchange

do you think we should add text about this? (if you do, please send 
text)

> For NICs a better solution would be to do an incremental checksum 
> verification and only over the ULP segment, so that the host stack 
> must complete the calculation by applying the increment from the 
> pseudo header, which can largely be cached, so the performance 
> advantages are almost completely preserved

i don't understand what do you mean by incremental checksum 
verification... could you expand on this?

Delivery-date: Thu, 28 Dec 2006 17:59:10 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: about the protection against on path attackers
Date: Thu, 28 Dec 2006 18:57:57 +0100
To: Iljitsch van Beijnum <[email-masked]>

Iljitsch in hiss review have raised the following issues w.r.t. the 
seuciryt of the shim6 protocol

my comments are inline

> Also, for CGA verification, don't we need to send the other side a 
> challenge to avoid replays?
>

I don't know if this is necessary...

I mean, the attack that we are considering is an attacker that can 
sniff an update request message and then will repeat it later on (i 
mean it cannot modify it, since it is protected by HBA/CGA) right?

what would be the effect of such attack? that an old locator set will 
be used instead of the new one, potentially leading to DoS attack. So, 
the effect of this would be a time shifted DoS attack (i.e. the 
attacker was once in the path, it can then later on, try to perform a 
DoS attack, hoping that none of the old locators are reachable now). I 
am not sure we need to provide protection against this attack... what 
do you think?

later on in his review, it is stated that:

>
>       context.  In this case, we are in the Context confusion 
> situation,
>       and the host MUST NOT use the old context to send any packets.  
> It
>       MAY just discard the old context (after all, the peer has
>       discarded it), or it MAY attempt to re-establish the old context
>       by sending a new I1 message and moving its state to I1-SENT.  In
>       any case, once that this situation is detected, the host MUST NOT
>       keep two contexts with overlapping Ls(peer) locator sets and the
>       same context tag in ESTABLISHED state, since this would result in
>       demultiplexing problems on the peer.
>
> What if an attacker is trying to interfere with legitimate 
> communication? We must be VERY sure that the new shim messages come 
> from the same host as the one that created the existing state if we're 
> going to mess with that existing state.
>

THe current security level is that we don't provide protection against 
on path attackers. If an attacker learns the context tag, then it can 
do some nasty stuff, including destroying the established context. this 
is the level of security that we have defined for the protocol. We can 
discuss whether this security level is approapriate, but i would like 
to have a high level discussion on the issue.

Delivery-date: Thu, 28 Dec 2006 16:46:27 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: error messages in shim6
Date: Thu, 28 Dec 2006 14:29:34 +0100
To: Iljitsch van Beijnum <[email-masked]>

Iljitsch has brought up the following issue in his review:

> More in general, most error conditions are handled by silently 
> dropping packets, however, which is a very bad idea because that way, 
> there is no difference between an error and lost messages.
>  So in some cases, a host may continue to resend the offending packet 
> because it doesn't know something went wrong. The main problem with 
> this approach is that you can't debug it from one end: you need to see 
> what happens on both ends to determine why something doesn't work.
>
> Silently dropping packets because of errors is the right approach for 
> security reasons in some cases, but I don't think this applies here. A 
> short error message with an error code and optionally a human-readable 
> message would be much better. As long as these error packets are 
> smaller than the packets that trigger them, there should be little or 
> no security impact, especially considering that we're prepared to talk 
> shim with the correspondent in question to begin with.
>

his proposal as you can see is to include a shim6 error message to 
handle this situations... any opinions?

Envelope-to: [email-masked]
Delivery-date: Wed, 20 Dec 2006 20:30:38 +0000
Message-Id: <[email-masked]>
To: Geoff Huston <[email-masked]>
cc: Fred Baker <[email-masked]>, [email-masked], Brian E Carpenter <[email-masked]>, Jari Arkko <[email-masked]>, [email-masked]
Subject: Re: IPR Notice 
Date: Wed, 20 Dec 2006 15:23:25 -0500
From: Thomas Narten <[email-masked]>

I'll probably regret this... :-)

Geoff Huston <[email-masked]> writes:

> The instruction of the ADs in this case was that the Working Group
> must be satisfied with the IPR claims in relation to technology that
> they are passing to the IESG for publication as proposed standards
> for SHIM6..

Right. The WG needs to either agree to ship the documents,
understanding they have associated IPR that might impact their ability
to ship products or for others to implement and ship products (which
presumably impacts how widely deployed the technology can become)...

Or, they need to decide that they can come up with an alternate
approach that "routes around" and avoids the known IPR
concerns. (Usually rather tricky, and does nothing to protect against
other IPR that we don't know about...)

Or, they need to conclude that they'd rather not advance the documents
at all, until or unless the IPR situation changes.

These are the basic choices, and I'd urge the WG stick with postings
that have direct bearing on answering these questions.

> I have voiced some objection to this instruction on the basis that I 
> know I am no IPR lawyer, and I suspect that the overall majority of 
> the SHIM6 WG are not IPR lawyers either, and the IETF would be better 
> advised to seek professional advice at the IESG level, but the 
> outcome of that discussion with the ADs was that IPR is a WG matter.

Actually, I do not see the point in having the IETF (or IESG) ask for
advice. Since this topic is all about potential liability to vendors
who ship potentially infringing technology, only those vendors can
decide what risk is acceptable for them (i.e., do they need a license,
are the stated terms and conditions acceptable to them, etc.) Vendors
employ their own legal folk for making those decisions and are not
likely to listen to what anybody else says, including the IETF.

What individuals should be doing is talking with their own legal teams
and getting opinions and education from their own legal
teams. Opinions of engineers are pretty much irrelevant in this space,
since the lawyers call the shots here.

Thomas

Delivery-date: Wed, 20 Dec 2006 07:15:58 +0000
Cc: Geoff Huston <[email-masked]>, [email-masked]
From: Fred Baker <[email-masked]>
Subject: Re: IPR Notice
Date: Tue, 19 Dec 2006 23:14:26 -0800
To: Jari Arkko <[email-masked]>

On Dec 19, 2006, at 10:08 PM, Jari Arkko wrote:
> I believe Fred's point was that there are matters that are specific  
> to this WG and other, more generic issues.

Yes. I have no doubt that the working group needs to discuss the  
points of the protocol and what it wants to do with any limitations  
that the declarations impose. An RFC 1988 declaration (Ericsson) and  
a royalty-free declaration (Microsoft), IMHO, impose very few limits  
on the WG - they simply preserve the companies' rights under the  
relevant law. They prevent the companies from getting sued by other  
companies over what are presumably their own inventions. If the  
statement was a RAND statement there would be more for the working  
group to discuss, but for outfits that are in fact reasonable in  
their dealings the "R" in "RAND" is normally a pretty good sign.

Going on to discuss, as we always and ever do, whether there is a  
place for IPR *at*all* in the IETF is significantly beyond the scope  
of the question Geoff posed to the list, and IMHO significantly  
beyond the scope of the shim6 charter. At that point, I called a  
process question, which I believe to have been appropriate.

Delivery-date: Wed, 20 Dec 2006 06:10:24 +0000
Date: Wed, 20 Dec 2006 08:08:09 +0200
From: Jari Arkko <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: Fred Baker <[email-masked]>,  [email-masked]
Subject: Re: IPR Notice

Geoff,
>
> The instruction of the ADs in this case was that the Working Group
> must be satisfied with the IPR claims in relation to technology that
> they are passing to the IESG for publication as proposed standards for
> SHIM6..
Indeed.
>
> I have voiced some objection to this instruction on the basis that I
> know I am no IPR lawyer, and I suspect that the overall majority of
> the SHIM6 WG are not IPR lawyers either, and the IETF would be better
> advised to seek professional advice at the IESG level, but the outcome
> of that discussion with the ADs was that IPR is a WG matter.
I feel your pain. Sorry, but its the way it is. We could
argue what the arrangement should be (I happen
to believe its still better this way), but this is not
the place to talk about that.
> So, according to the above stipulation then this is a necessary
> conversation. for this working group.
>
> In this case my call is that if you believe otherwise, please take the
> matter to the ADs.
Clarification. I believe Fred's point was that there are matters
that are specific to this WG and other, more generic issues.
The matter for the WG is whether they are happy with the
documents with all of their features, including algorithms,
protocol bits, descriptions, IPRs, and all. And specifically,
we have received a new IPR declaration, does that change
what the working group thought earlier? And that
does involve looking at the details -- there is a significant
difference between, say, "royalty-free" and "reasonable"...

But if there are issues such as that the IETF IPR rules
should change or that we should go search for a planet
without IPR (both issues I fully agree with). These seem
to be fodder for more general work at the IETF. Perhaps
the interested parties should get together and form a
list to talk about that? I would certainly be interested
because I believe the IETF IPR rules are too relaxed.

--Jari

Delivery-date: Tue, 19 Dec 2006 22:30:09 +0000
Date: Wed, 20 Dec 2006 09:28:01 +1100
To: Fred Baker <[email-masked]>, [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Re: IPR Notice
Cc: Brian E Carpenter <[email-masked]>, Jari Arkko <[email-masked]>, [email-masked]

At 11:50 PM 19/12/2006, Fred Baker wrote:
>On Dec 19, 2006, at 7:04 AM, Bound, Jim wrote:
>>I simply do not agree.  IETF should say: Do not bring your IPR to
>>the IETF unless you are giving it away with NO STRINGS attached.
>>Simple.  If you do it will not be used.  We are certainly capable
>>of inventing our own work based on the many persons in this community.
>
>Point of Order...
>
>At this point, haven't we overstepped the charter of shim6 and moved
>into the charter of ietf-ipr?

No, I don't believe so

The instruction of the ADs in this case was that the Working Group 
must be satisfied with the IPR claims in relation to technology that 
they are passing to the IESG for publication as proposed standards for SHIM6..

I have voiced some objection to this instruction on the basis that I 
know I am no IPR lawyer, and I suspect that the overall majority of 
the SHIM6 WG are not IPR lawyers either, and the IETF would be better 
advised to seek professional advice at the IESG level, but the 
outcome of that discussion with the ADs was that IPR is a WG matter.

So, according to the above stipulation then this is a necessary 
conversation. for this working group.

In this case my call is that if you believe otherwise, please take 
the matter to the ADs.

Thanks,

   Geoff

Delivery-date: Tue, 19 Dec 2006 17:59:24 +0000
Content-class: urn:content-classes:message
Subject: RE: IPR Notice
Date: Tue, 19 Dec 2006 12:56:56 -0500
From: "Bound, Jim" <[email-masked]>
To: "Fred Baker" <[email-masked]>, <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>, "Jari Arkko" <[email-masked]>, "Geoff Huston" <[email-masked]>, <[email-masked]>

Yes I am willing to end this discussion if others are for sure.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Fred Baker
> Sent: Tuesday, December 19, 2006 7:51 AM
> To: [email-masked]
> Cc: Brian E Carpenter; Jari Arkko; Geoff Huston; [email-masked]
> Subject: Re: IPR Notice
> 
> On Dec 19, 2006, at 7:04 AM, Bound, Jim wrote:
> > I simply do not agree.  IETF should say: Do not bring your 
> IPR to the 
> > IETF unless you are giving it away with NO STRINGS attached.
> > Simple.  If you do it will not be used.  We are certainly 
> capable of 
> > inventing our own work based on the many persons in this community.
> 
> Point of Order...
> 
> At this point, haven't we overstepped the charter of shim6 
> and moved into the charter of ietf-ipr?
> 
> 

Delivery-date: Tue, 19 Dec 2006 13:17:16 +0000
Date: Tue, 19 Dec 2006 14:15:55 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Fred Baker <[email-masked]>
CC: [email-masked], Jari Arkko <[email-masked]>, Geoff Huston <[email-masked]>, [email-masked]
Subject: Re: IPR Notice

Fred Baker wrote:
> On Dec 19, 2006, at 7:04 AM, Bound, Jim wrote:
> 
>> I simply do not agree.  IETF should say: Do not bring your IPR to  the 
>> IETF unless you are giving it away with NO STRINGS attached.  Simple.  
>> If you do it will not be used.  We are certainly capable  of inventing 
>> our own work based on the many persons in this community.
> 
> 
> Point of Order...
> 
> At this point, haven't we overstepped the charter of shim6

I think so.

> and moved  
> into the charter of ietf-ipr?

Actually, not, since only copyright questions are in scope in ipr at present.

    Brian

Delivery-date: Tue, 19 Dec 2006 12:52:53 +0000
Cc: Brian E Carpenter <[email-masked]>, Jari Arkko <[email-masked]>, Geoff Huston <[email-masked]>, [email-masked]
From: Fred Baker <[email-masked]>
Subject: Re: IPR Notice
Date: Tue, 19 Dec 2006 07:50:32 -0500
To: [email-masked]

On Dec 19, 2006, at 7:04 AM, Bound, Jim wrote:
> I simply do not agree.  IETF should say: Do not bring your IPR to  
> the IETF unless you are giving it away with NO STRINGS attached.  
> Simple.  If you do it will not be used.  We are certainly capable  
> of inventing our own work based on the many persons in this community.

Point of Order...

At this point, haven't we overstepped the charter of shim6 and moved  
into the charter of ietf-ipr?

Delivery-date: Tue, 19 Dec 2006 12:05:57 +0000
Content-class: urn:content-classes:message
Subject: RE: IPR Notice
Date: Tue, 19 Dec 2006 07:04:01 -0500
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>, "Tony Li" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>, "tom.petch" <[email-masked]>, "Geoff Huston" <[email-masked]>, <[email-masked]>

I simply do not agree.  IETF should say: Do not bring your IPR to the
IETF unless you are giving it away with NO STRINGS attached. Simple.  If
you do it will not be used.  We are certainly capable of inventing our
own work based on the many persons in this community. I have seen cases
in the past where good intentioned engineers bring work to the IETF and
then their company requires IPR.  But not lately.

/jim

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, December 19, 2006 4:25 AM
> To: Tony Li
> Cc: Bound, Jim; Jari Arkko; tom.petch; Geoff Huston; [email-masked]
> Subject: Re: IPR Notice
> 
> I agree that the devil is in the details, and each 
> implementer has to take their own decisions. But if the IETF 
> can't take IPR disclosures at face value, we may as well give up.
> There is no real world in which patent claims will not be made.
> 
>      Brian
> 
> Tony Li wrote:
> > 
> > Brian,
> > 
> > There is allegedly at least one royalty-free IPR agreement floating 
> > around that stipulates that the licensee not sue the 
> licensor on ANY 
> > IPR claim.  If this agreed to, then the licensor can turn 
> around and 
> > violate any number of the licensee's IPR rights with impunity.
> > 
> > If this is accurate, this is an example that shows that 
> royalty-free 
> > does not necessarily mean  constraint free.  It also does not mean  
> > 'not onerous'.
> > 
> > Caveat emptor,
> > Tony
> > 
> > 
> > On Dec 18, 2006, at 7:11 AM, Brian E Carpenter wrote:
> > 
> >> Jim, since one is a non-assert disclosure and the other is a 
> >> royalty-free disclosure, why do you say that?
> >>
> >>     Brian
> >>
> >> Bound, Jim wrote:
> >>
> >>> Makes it even more scary to implement IMHO as product.
> >>> /jim
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] 
> On Behalf  
> >>>> Of Jari Arkko
> >>>> Sent: Monday, December 18, 2006 4:34 AM
> >>>> To: tom.petch
> >>>> Cc: Geoff Huston; [email-masked]
> >>>> Subject: Re: IPR Notice
> >>>>
> >>>>
> >>>>
> >>>>>> How does this affect the Ericsson claim last April which, as I 
> >>>>>> recall, said that Ericsson would not assert its rights
> >>>>
> >>>>
> >>>> unless anyone
> >>>>
> >>>>>> claimed against Ericsson.
> >>>>>> Does this claim constitute such a claim against Ericsson?
> >>>>>>
> >>>>
> >>>> I am not a lawyer either, but I believe that is something that 
> >>>> affects only those two companies, i.e. Microsoft and Ericsson.
> >>>> FWIW, my understanding is that this does not change Ericsson's 
> >>>> thinking or implementation plans.
> >>>>
> >>>> For everyone else, nothing changed except that there is now a 
> >>>> second IPR declaration. The relevant information in the new IPR 
> >>>> declaration is Microsoft's conditions, i.e., no royalty etc.
> >>>> Personally, those conditions look fine to me.
> >>>>
> >>>> --Jari
> >>>>
> >>>>
> >>>>
> >>
> > 
> > 
> 

Delivery-date: Tue, 19 Dec 2006 09:27:55 +0000
Date: Tue, 19 Dec 2006 10:25:05 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Tony Li <[email-masked]>
CC: "Bound, Jim" <[email-masked]>, Jari Arkko <[email-masked]>, "tom.petch" <[email-masked]>, Geoff Huston <[email-masked]>, [email-masked]
Subject: Re: IPR Notice

I agree that the devil is in the details, and each implementer
has to take their own decisions. But if the IETF can't
take IPR disclosures at face value, we may as well give up.
There is no real world in which patent claims will not
be made.

     Brian

Tony Li wrote:
> 
> Brian,
> 
> There is allegedly at least one royalty-free IPR agreement floating  
> around that stipulates that the licensee not sue the licensor on ANY  
> IPR claim.  If this agreed to, then the licensor can turn around and  
> violate any number of the licensee's IPR rights with impunity.
> 
> If this is accurate, this is an example that shows that royalty-free  
> does not necessarily mean  constraint free.  It also does not mean  'not 
> onerous'.
> 
> Caveat emptor,
> Tony
> 
> 
> On Dec 18, 2006, at 7:11 AM, Brian E Carpenter wrote:
> 
>> Jim, since one is a non-assert disclosure and the other
>> is a royalty-free disclosure, why do you say that?
>>
>>     Brian
>>
>> Bound, Jim wrote:
>>
>>> Makes it even more scary to implement IMHO as product.
>>> /jim
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf  Of 
>>>> Jari Arkko
>>>> Sent: Monday, December 18, 2006 4:34 AM
>>>> To: tom.petch
>>>> Cc: Geoff Huston; [email-masked]
>>>> Subject: Re: IPR Notice
>>>>
>>>>
>>>>
>>>>>> How does this affect the Ericsson claim last April which, as I  
>>>>>> recall, said that Ericsson would not assert its rights
>>>>
>>>>
>>>> unless anyone
>>>>
>>>>>> claimed against Ericsson.
>>>>>> Does this claim constitute such a claim against Ericsson?
>>>>>>
>>>>
>>>> I am not a lawyer either, but I believe that is something that  
>>>> affects only those two companies, i.e. Microsoft and Ericsson.  
>>>> FWIW, my understanding is that this does not change Ericsson's  
>>>> thinking or implementation plans.
>>>>
>>>> For everyone else, nothing changed except that there is now a  
>>>> second IPR declaration. The relevant information in the new IPR  
>>>> declaration is Microsoft's conditions, i.e., no royalty etc.  
>>>> Personally, those conditions look fine to me.
>>>>
>>>> --Jari
>>>>
>>>>
>>>>
>>
> 
> 

Delivery-date: Mon, 18 Dec 2006 18:39:35 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: teardown of the ULID-pair context
Date: Mon, 18 Dec 2006 19:39:18 +0100
To: Matthijs Mekking <[email-masked]>

El 12/12/2006, a las 14:47, Matthijs Mekking escribió:

> Hi,
>
> I have a question about the teardown of the ULID-pair context. In
> chapter 9, the proto6 draft says "A reasonable approach would be not to
> tear down a context until at least 5 minutes have passed since the last
> message was sent or received using the context." Does this include
> messages that do not contain a shim6 extension header? My opinion is 
> yes:
>

yes, of course

please note that the REAP protcool for instance actually processes the 
payload packets in some form, since it activates timers based on 
recieved and sent payload packets, so, in any case the payload packets

> If there is a context on host A for host B, this means that both are
> multihomed. They should enjoy the goals of multihoming, such as
> failover. However, the communication between A and B initially uses the
> ULID address pair. Therefore, the IPv6 address fields do not need to be
> replaced by a different locator pair, and the message is not tagged 
> with
> a shim6 extension header. In other words, the context is not being used
> at the moment. This means that if after 5 minutes there was no context
> switch, the context states may be teared down again. If shortly after
> this the link corresponding to the ULID pair fails, the hosts are not
> able to do failover anymore.
>
> So, shim unaware payloads (traffic not using the context) should also 
> be
> observed. I suggest that the text 'using the context' in chapter 9 will
> be removed.

as i mention above, the payload packets (not carrying the payload shim6 
header) are using the context and have an impact on the context state 
(e.g. w.r.t. timers)

in any case, i can rephrase it more clearly, and explicitly mention 
that this does include data packets without the payload header

>
> In order to observer shim unaware payloads, the shim6 layer should look
> up a context for these kind of messages. Chapter 11 already defines how
> this should be done for sending ULP payloads. For receiving packets
> (chapter 12), this information is missing. I suggest there should be a
> section before 12.1 receiving payload extension headers:
>
> 12.x Receiving payload without extension headers
>
> The receiver extracts the IPv6 source and destination fields, and uses
> this to find a ULID-pair context, such that the IPv6 address fields
> match the ULID(local) and ULID(peer). If such a context is found, the
> context appears not to be quiescent and this should be remembered. The
> host continues with proceeding the message.

yes, this makes sense.... actually it should be noted more clearly in 
the spec that data packets without shim6 payload header do actually 
need processing in the shim6 ctxt state... this is particularly 
critical for the reap protocol, which sets and stops timers upon the 
recpetion and sending these packets... i will try to add something in 
these lines...

thanks again, regards, marcelo

>
>
>
> With regards,
>
> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
>

Delivery-date: Mon, 18 Dec 2006 18:34:21 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: Retransmission of I2 messages
Date: Mon, 18 Dec 2006 19:33:54 +0100
To: Matthijs Mekking <[email-masked]>

Hi,

El 11/12/2006, a las 10:02, Matthijs Mekking escribió:

> Hi,
>
> I have a question about the proto draft. In section 7.12, the draft 
> says
>  "If the initiator does not receive an R2 message after I2_TIMEOUT time
> after sending an I2 message it MAY retransmit the I2 message" and "Thus
> the initiator SHOULD fall back to retransmitting the I1 message when
> there is no R2 received after retransmitting the I2 message
> I2_RETRIES_MAX times."
>
> I am concerned about keywords MAY and SHOULD in section 7.12. If an
> implementation decides not to implement these retransmissions, then
> according to the protocol specification, the fall back to 
> retransmitting
> I1 messages would never occur (because this SHOULD happen after
> I2_RETRIES_MAX retransmissions of I2). If the I2 is not accepted by the
> responder, and no retransmissions are sent, than the context would stay
> in I2-SENT, and is never able to reach ESTABLISHED.
>
> I think the host MAY retransmit I2 messages, but MUST fall back after a
> certain amount of time, to avoid this deadlock situation. The same
> applies for retransmitting I2bis messages.
>

yes, the idea is that the initiator may retransmit I2 but should 
retransmit I1

i will try to rephrase this more clearly to avoid the deadlock 
situation that you accurely describe

thanks, marcelo

> Furthermore, last week I have sent an e-mail with questions about the
> proto6 draft (http://ops.ietf.org/lists/shim6/msg01738.html). I would 
> be
> very grateful if someone could answer them.
>
> With kind regards,
>
> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
>

Delivery-date: Mon, 18 Dec 2006 18:21:01 +0000
Cc: Brian E Carpenter <[email-masked]>, "Bound, Jim" <[email-masked]>, [email-masked]
From: Tony Li <[email-masked]>
Subject: Re: IPR Notice
Date: Mon, 18 Dec 2006 10:20:40 -0800
To: Jari Arkko <[email-masked]>

Thanks.  The rumor that I heard was actually about a different IPR  
claim, from another company entirely.

Tony

On Dec 18, 2006, at 9:49 AM, Jari Arkko wrote:

> Tony,
>
> (Speaking personally...)
>
> In case you didn't follow earlier discussions -- there
> was complaint earlier about Ericsson's IPR declaration
> requiring too much in terms of what the users may not
> do wrt their own IPR & Ericsson. I talked to our licensing
> department who agreed to limit the scope from ANY to
> IPR relating to IETF standards, and post the updated
> declaration once the WG process was otherwise done.
> So the declaration that is up on the web right now does
> not reflect the final status.
>
> Hope this helps,
>
> --Jari
>

Delivery-date: Mon, 18 Dec 2006 18:14:00 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: questions about draft-ietf-shim6-proto-06.txt
Date: Mon, 18 Dec 2006 19:13:35 +0100
To: Matthijs Mekking <[email-masked]>

Hi,

sorry for the late reply...

thank you very much for your careful review.

see below...

El 05/12/2006, a las 14:54, Matthijs Mekking escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> My name is Matthijs, and I am doing research on shim6 for Radboud
> University Nijmegen/NLnetLabs Amsterdam (Netherlands). I have a couple
> of questions about draft-ietf-shim6-proto-06.txt that seem a bit 
> unclear
> to me. Some of them are maybe obvious comments, but I shall make them,
> because I think it is good for a protocol description to allow only one
> clear interpretation.
>

agree

> 1. Wat is exactly meant with VALIDATOR_MIN_LIFETIME? According to the
> draft, "the peer might reject Responder Validator options that are 
> older
> than VALIDATOR_MIN_LIFETIME to avoid replay attacks" and "Nonces that
> are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent".
> Does this value apply to both nonces and responder validator options?
>

this is what is stated in the current draft as you quote

> Is this value solely used by a host acting as responder?
>

yes, the initiator does not use this constant afaict

> If so, do you agree that this value should be used outside SHIM6?

not sure what you mean here....

> Because a responder may not store state (yet) and thus can not verify 
> if
> a nonce in an I2 or I2bis message may be considered recent.

the idea here is to minimize the state associated to a new context 
until we are sure that the initiator really wants to establish a 
context (and this is not a DoS attack aimed to consume resources)

so the point is that there is no context information stored (but it is 
ok to have host state, not associated to any not yet existent context)

The idea then is that the responder has only a Secret S and a Responder 
nonce that he is incrementing each time it receives a new I1.

So i guess that in order to verify that the responder nonce and the 
validator is recent, it will need to store the time each responder 
nonce was generated. this would indeed imply a context specific state 
that is what we are trying to avoid.

Another option would be that the responder nonces are simply the clock 
value and so there is no need to store information about the generation 
time of each responder nonce (this would work as long that the Secret S 
is modified at least once each time the responder nonces are rollover)
In this case, we can obtain the same behaviour without requiring even 
to store the time of generation of each responder nonce, what do you 
think?

> If you
> agree, can't this value be omitted from the document (since it is
> independent of the correct working of SHIM6, but merely a security
> consideration of the host)?
>

i don't think so, this is important to provide the security against DoS 
and replay attacks, so i think it is needed and we should keep it. 
However, as you mention, the current suggestion for generating the 
responder validator would result in some state per received I1 afaict, 
so i would suggest to change the way the responder nonce counter is 
incremented....

>
>
>
> 2. In addition, when generating a responder validator, the draft talks
> abouot increasing a counter, and using the counter value as responder
> nonce. Is this the same way how the responder and initiator computes
> their other INIT nonces and RESP nonces?
>

please note that section 7.10.1.  Generating the R1 Validator where it 
is mentioned that the responder nonce is generated by using a counter 
value is a suggestion (just an example).  a node can generate the 
values as it plesases as long they are used as described in the other 
sections of the spec.

>
>
>
> 3. In section 7.12, the host MAY retransmit I2. Why is this a MAY and
> not a SHOULD?
>

because the important thing is that the initiator retries to establish 
the context. However retrying with an I2 may not be a good strategy, 
because the validator information may be expired. So, the host may 
retransmit I2 (if he wants to take the risk that the validator 
information is expired) but in any case it needs to fall back to send a 
new I1 in any case, makes sense?
>
>
>
> 4. The draft considers a context in state IDLE the same as a context
> being non-existing. However, the state machine in appendix B says that
> context in state E-FAILED of state NO-SUPPORT should behave the same as
> if it was in IDLE. Does this mean when chapter 7 speaks of 'if no
> context is found, the host should ... (do something useful)' this also
> applies to if a context is found and the state is E-FAILED or
> NO-SUPPORT? For example in section 7.9: "If no state is found (i.e., 
> the
> state is IDLE), then the host replies with a R1 message as specified
> below." Does a host needs to reply with R1 if a context is found that 
> is
> in state E-FAILED or NO-SUPPORT?
>

E-Failed and No_support states are basically due to the fact that the 
attempts to initiate a context have failed.

So, i guess that in case that some packets, like a payload packet or 
similar, it should behave as idle, since the goal of the e failed and 
no support states are simply to avoid the retrials of the initiator, in 
case that it seems that is not possible to establish the context.

So i would say that the main characteristics of the efailed and no 
support basically affect the behaviour of the node as an initator and 
not as a reciver, so, it should behave as a normal receiver in idle 
state

>
>
>
> 5. In chapter 6, a conceptual model of the host is given. However, the
> second table in section 6.2 introduces some new elements that are not
> described in section 6.1: INIT nonce, RESP nonce and CT(R1bis). I
> suggest that they (including a short description) are added to section 
> 6.1.
>

with respect to init nonce, this value is only used during the context 
exchange,
with respect to the responder nonce, if we rephrase as above, then the 
only thing needed is a clock (and eventually the secret S value, but 
this is implementation dependent) and it is not associated to any 
specific context

otoh, the other information described in section 6.1. is stable context 
information, so i guess we havent' included this info there is because 
it is seen as transient information... otoh, i think it may be 
interesting to include the information because it is critical to the 
context exchange procedure... not sure...

the CT(R1bis) is generated from the payload packet received and it is 
only stored during the context recovery phase, so i am not convinced it 
would be so useful to describe it here...

please note that this section is a model and it is not mandatory

>
>
>
> 6. Am I right that the RESP nonce in I2-SENT is stored so that the host
> is able to create the correct I2 retransmission?

if you want to retransmit the I2, then yes.

>  If so, than the
> responder validator should also be stored (because this is also copied
> from the R1 message, just like RESP nonce).

agree, need to add this to the table...

>  If this is the reason, than
> I think RESP nonce, INIT nonce and the responder validator should also
> be stored in state I2BIS-SENT.
>

yes, need to add the RESP nonce and INIT nonce and validator in the 
I2BISSENT state

>
>
>
> 7. In the text, computing a responder validator looks inconsistent with
> generating the validator:
>
> For R1 the secret S, the Initiator Context Tag and the locators are
> omitted when computing the validator:
>
> "use the following information concatenated as input to the one-way
> function:
> o  The the secret S
> o  That Responder Nonce
> o  The Initiator Context Tag from the I1 message
> o  The ULIDs from the I1 message
> o  The locators from the I1 message (strictly only needed if they are
> different from the ULIDs)
> o  The forked instance identifier if such option was included in the
> I1 message"
> (section 7.10.1, page 62)
>
> and
>
> "that the Responder Validator option matches the validator the host
> would have computed for the ULID, locators, responder nonce, and FII."
> (section 7.13, page 63).
>

the locators are included in the text afaict....

w.r.t. the S value, the validator needs to be verified in a coherent 
way in which it was generated, but as i mentioned earlier, the 
description f how to generate a validator is just an example, so the 
secret S for instance is just a suggestion.

the init nonce should be added indeed

> For R1bis the secret S and Receiver Context tag are omitted when
> computing the validator, but the ULID and FII are added:
>
> "use the following information concatenated as input to the one-way
> function:
> o  The the secret S
> o  That Responder Nonce
> o  The Receiver Context tag included in the received packet
> o  The locators from the received packet"
> (section 7.17.1, page 68)
>
> and
>
> "the Responder Validator option matches the validator the host would
> have computed for the ULID, locators, responder nonce, and FII as part
> of sending an R1bis message."
> (section 7.20, page 69)
>

the value S, the same consderation than above...

the ULID and FII, agree need to be removed from the verification, since 
they are not availble for generation

the receiver context add should be added to the verification procedure.

Regards, marcelo

>
> With kind regards,
>
> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFdXocNiaStnTWEtYRAo3nAKC+sB2E/8YxJQ6PR7AzORZ6gEKyOgCeJccj
> UQAPF0SpqzlfSZT7smcf++k=
> =P4tt
> -----END PGP SIGNATURE-----
>

Delivery-date: Mon, 18 Dec 2006 17:50:30 +0000
Date: Mon, 18 Dec 2006 19:49:18 +0200
From: Jari Arkko <[email-masked]>
To: Tony Li <[email-masked]>
CC: Brian E Carpenter <[email-masked]>,  "Bound, Jim" <[email-masked]>, [email-masked]
Subject: Re: IPR Notice

Tony,

(Speaking personally...)

In case you didn't follow earlier discussions -- there
was complaint earlier about Ericsson's IPR declaration
requiring too much in terms of what the users may not
do wrt their own IPR & Ericsson. I talked to our licensing
department who agreed to limit the scope from ANY to
IPR relating to IETF standards, and post the updated
declaration once the WG process was otherwise done.
So the declaration that is up on the web right now does
not reflect the final status.

Hope this helps,

--Jari

Delivery-date: Mon, 18 Dec 2006 16:49:50 +0000
Cc: "Bound, Jim" <[email-masked]>, Jari Arkko <[email-masked]>, "tom.petch" <[email-masked]>, Geoff Huston <[email-masked]>, [email-masked]
From: Tony Li <[email-masked]>
Subject: Re: IPR Notice
Date: Mon, 18 Dec 2006 08:49:06 -0800
To: Brian E Carpenter <[email-masked]>

Brian,

There is allegedly at least one royalty-free IPR agreement floating  
around that stipulates that the licensee not sue the licensor on ANY  
IPR claim.  If this agreed to, then the licensor can turn around and  
violate any number of the licensee's IPR rights with impunity.

If this is accurate, this is an example that shows that royalty-free  
does not necessarily mean  constraint free.  It also does not mean  
'not onerous'.

Caveat emptor,
Tony

On Dec 18, 2006, at 7:11 AM, Brian E Carpenter wrote:

> Jim, since one is a non-assert disclosure and the other
> is a royalty-free disclosure, why do you say that?
>
>     Brian
>
> Bound, Jim wrote:
>> Makes it even more scary to implement IMHO as product.
>> /jim
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf  
>>> Of Jari Arkko
>>> Sent: Monday, December 18, 2006 4:34 AM
>>> To: tom.petch
>>> Cc: Geoff Huston; [email-masked]
>>> Subject: Re: IPR Notice
>>>
>>>
>>>
>>>>> How does this affect the Ericsson claim last April which, as I  
>>>>> recall, said that Ericsson would not assert its rights
>>>
>>> unless anyone
>>>>> claimed against Ericsson.
>>>>> Does this claim constitute such a claim against Ericsson?
>>>>>
>>>
>>> I am not a lawyer either, but I believe that is something that  
>>> affects only those two companies, i.e. Microsoft and Ericsson.  
>>> FWIW, my understanding is that this does not change Ericsson's  
>>> thinking or implementation plans.
>>>
>>> For everyone else, nothing changed except that there is now a  
>>> second IPR declaration. The relevant information in the new IPR  
>>> declaration is Microsoft's conditions, i.e., no royalty etc.  
>>> Personally, those conditions look fine to me.
>>>
>>> --Jari
>>>
>>>
>>>
>

Delivery-date: Mon, 18 Dec 2006 16:27:42 +0000
Content-class: urn:content-classes:message
Subject: RE: IPR Notice
Date: Mon, 18 Dec 2006 11:26:28 -0500
From: "Bound, Jim" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>, "tom.petch" <[email-masked]>, "Geoff Huston" <[email-masked]>, <[email-masked]>

Brian,

Re-Read the fine print and interpretations that can be made.  Royalty
free at what cost?  Now we have two IPRs for technology that could
widely pervasive for a long time and solve problems I am not clear even
need to be solved.  Not exactly MUST or even NICE to HAVE from product
market view.  This is just my opinion and not shared by my company or
any other affiliation.  I am against any form of this in the IETF now it
has to stop.

Thanks
/jim 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Monday, December 18, 2006 10:11 AM
> To: Bound, Jim
> Cc: Jari Arkko; tom.petch; Geoff Huston; [email-masked]
> Subject: Re: IPR Notice
> 
> Jim, since one is a non-assert disclosure and the other is a 
> royalty-free disclosure, why do you say that?
> 
>      Brian
> 
> Bound, Jim wrote:
> > Makes it even more scary to implement IMHO as product.
> > /jim
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> >>Jari Arkko
> >>Sent: Monday, December 18, 2006 4:34 AM
> >>To: tom.petch
> >>Cc: Geoff Huston; [email-masked]
> >>Subject: Re: IPR Notice
> >>
> >>
> >>
> >>>>How does this affect the Ericsson claim last April which, as I 
> >>>>recall, said that Ericsson would not assert its rights
> >>
> >>unless anyone
> >>
> >>>>claimed against Ericsson.
> >>>>Does this claim constitute such a claim against Ericsson?
> >>>>
> >>
> >>I am not a lawyer either, but I believe that is something 
> that affects 
> >>only those two companies, i.e. Microsoft and Ericsson. FWIW, my 
> >>understanding is that this does not change Ericsson's thinking or 
> >>implementation plans.
> >>
> >>For everyone else, nothing changed except that there is now 
> a second 
> >>IPR declaration. The relevant information in the new IPR 
> declaration 
> >>is Microsoft's conditions, i.e., no royalty etc. Personally, those 
> >>conditions look fine to me.
> >>
> >>--Jari
> >>
> >>
> >>
> > 
> > 
> > 
> 

Delivery-date: Mon, 18 Dec 2006 15:12:07 +0000
Date: Mon, 18 Dec 2006 16:11:20 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Bound, Jim" <[email-masked]>
CC: Jari Arkko <[email-masked]>, "tom.petch" <[email-masked]>, Geoff Huston <[email-masked]>, [email-masked]
Subject: Re: IPR Notice

Jim, since one is a non-assert disclosure and the other
is a royalty-free disclosure, why do you say that?

     Brian

Bound, Jim wrote:
> Makes it even more scary to implement IMHO as product.
> /jim 
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of Jari Arkko
>>Sent: Monday, December 18, 2006 4:34 AM
>>To: tom.petch
>>Cc: Geoff Huston; [email-masked]
>>Subject: Re: IPR Notice
>>
>>
>>
>>>>How does this affect the Ericsson claim last April which, as I 
>>>>recall, said that Ericsson would not assert its rights 
>>
>>unless anyone 
>>
>>>>claimed against Ericsson.
>>>>Does this claim constitute such a claim against Ericsson?
>>>>
>>
>>I am not a lawyer either, but I believe that is something 
>>that affects only those two companies, i.e. Microsoft and 
>>Ericsson. FWIW, my understanding is that this does not change 
>>Ericsson's thinking or implementation plans.
>>
>>For everyone else, nothing changed except that there is now a 
>>second IPR declaration. The relevant information in the new 
>>IPR declaration is Microsoft's conditions, i.e., no royalty 
>>etc. Personally, those conditions look fine to me.
>>
>>--Jari
>>
>>
>>
> 
> 
> 

Delivery-date: Mon, 18 Dec 2006 14:31:04 +0000
Content-class: urn:content-classes:message
Subject: RE: IPR Notice
Date: Mon, 18 Dec 2006 09:28:45 -0500
From: "Bound, Jim" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "tom.petch" <[email-masked]>
Cc: "Geoff Huston" <[email-masked]>, <[email-masked]>

Makes it even more scary to implement IMHO as product.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Monday, December 18, 2006 4:34 AM
> To: tom.petch
> Cc: Geoff Huston; [email-masked]
> Subject: Re: IPR Notice
> 
> 
> >> How does this affect the Ericsson claim last April which, as I 
> >> recall, said that Ericsson would not assert its rights 
> unless anyone 
> >> claimed against Ericsson.
> >> Does this claim constitute such a claim against Ericsson?
> >>
> I am not a lawyer either, but I believe that is something 
> that affects only those two companies, i.e. Microsoft and 
> Ericsson. FWIW, my understanding is that this does not change 
> Ericsson's thinking or implementation plans.
> 
> For everyone else, nothing changed except that there is now a 
> second IPR declaration. The relevant information in the new 
> IPR declaration is Microsoft's conditions, i.e., no royalty 
> etc. Personally, those conditions look fine to me.
> 
> --Jari
> 
> 
> 

Delivery-date: Mon, 18 Dec 2006 09:36:12 +0000
Date: Mon, 18 Dec 2006 11:34:27 +0200
From: Jari Arkko <[email-masked]>
To: "tom.petch" <[email-masked]>
CC: Geoff Huston <[email-masked]>,  [email-masked]
Subject: Re: IPR Notice

>> How does this affect the Ericsson claim last April which, as I
>> recall, said that
>> Ericsson would not assert its rights unless anyone claimed against
>> Ericsson.
>> Does this claim constitute such a claim against Ericsson?
>>
I am not a lawyer either, but I believe that is
something that affects only those two companies,
i.e. Microsoft and Ericsson. FWIW, my understanding
is that this does not change Ericsson's thinking
or implementation plans.

For everyone else, nothing changed except that
there is now a second IPR declaration. The
relevant information in the new IPR declaration is
Microsoft's conditions, i.e., no royalty etc. Personally,
those conditions look fine to me.

--Jari

Delivery-date: Sun, 17 Dec 2006 23:50:23 +0000
Date: Mon, 18 Dec 2006 10:46:01 +1100
To: "tom.petch" <[email-masked]>, <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: IPR Notice
Cc: <[email-masked]>

This is a claim by Microsoft, not Cisco.

But as I'm not an IPR lawyer the best advice I can offer in response 
is "I don't have a clue."

regards,

    Geoff

At 02:40 AM 17/12/2006, tom.petch wrote:
>How does this affect the Ericsson claim last April which, as I 
>recall, said that
>Ericsson would not assert its rights unless anyone claimed against Ericsson.
>Does this claim by Cisco constitute such a claim against Ericsson?
>
>Tom Petch
>
>
>----- Original Message -----
>From: "Geoff Huston" <[email-masked]>
>To: <[email-masked]>
>Cc: <[email-masked]>
>Sent: Friday, December 15, 2006 6:55 PM
>Subject: IPR Notice
>
>
> > An IPR disclosure that pertains to the Internet-Draft entitled "Hash
> > Based Addresses (HBA)" (draft-ietf-shim6-hba) was submitted to the
> > IETF Secretariat on 2006-11-09 and has been posted on the "IETF Page
> > of Intellectual Property Rights Disclosures"
> > (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the
> > IPR disclosure is "Microsoft's Statement about IPR claimed in
> > draft-ietf-shim6-hba-01." Its Claim Number 762, in the section
> > "Specific IPR Disclosures", submitted on the 9th November.
> >
> > The disclosure has ticked the box:
> >
> > Royalty-Free, Reasonable, and Non-Discriminatory License to All 
> Implementers.
> >
> > and  also ticked:
> >
> > This licensing declaration is limited solely to standards-track IETF
>documents.
> >
> > Section 8 of RFC3979 states:
> >
> >    "In general, IETF working groups prefer technologies with no known
> > IPR claims or, for technologies with claims against them, an offer of
> > royalty-free licensing.  But IETF working groups have the discretion
> > to adopt technology with a commitment of fair and non-discriminatory
> > terms, or even with no licensing commitment, if they feel that this
> > technology is superior enough to alternatives with fewer IPR claims
> > or free licensing to outweigh the potential cost of the licenses.
> >
> >
> > Are there any comments about the viability of HBA approach in the
> > light of this, or do WG members think that the royalty-Free
> > Non-Discriminatory terms are acceptable in this case?
> >
> > regards,
> >
> >    Geoff & Kurtis
> >
> >
> >

Delivery-date: Fri, 15 Dec 2006 17:57:23 +0000
Date: Sat, 16 Dec 2006 04:55:26 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Notice of IPR
Cc: [email-masked]

An IPR disclosure that pertains to the Internet-Draft entitled "Hash 
Based Addresses (HBA)" (draft-ietf-shim6-hba) was submitted to the 
IETF Secretariat on 2006-11-09 and has been posted on the "IETF Page 
of Intellectual Property Rights Disclosures" 
(https://datatracker.ietf.org/public/ipr_list.cgi). The title of the 
IPR disclosure is "Microsoft's Statement about IPR claimed in 
draft-ietf-shim6-hba-01." Its Claim Number 762, in the section 
"Specific IPR Disclosures", submitted on the 9th November.

The disclosure has ticked the box:

Royalty-Free, Reasonable, and Non-Discriminatory License to All Implementers.

and  also ticked:

This licensing declaration is limited solely to standards-track IETF documents.

Section 8 of RFC3979 states:

   "In general, IETF working groups prefer technologies with no known 
IPR claims or, for technologies with claims against them, an offer of 
royalty-free licensing.  But IETF working groups have the discretion 
to adopt technology with a commitment of fair and non-discriminatory 
terms, or even with no licensing commitment, if they feel that this 
technology is superior enough to alternatives with fewer IPR claims 
or free licensing to outweigh the potential cost of the licenses.

Are there any comments about the viability of HBA approach in the 
light of this, or do WG members think that the royalty-Free 
Non-Discriminatory terms are acceptable in this case?

regards,

   Geoff & Kurtis

Delivery-date: Thu, 14 Dec 2006 20:48:03 +0000
Date: Thu, 14 Dec 2006 14:31:26 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Congestion issue [Re: shim6-proto-07 review]

Iljitsch van Beijnum wrote:
...
> 2. Congestion
> 
> There is no discussion of congestion issues when the shim moves  ongoing communicaiton to another locator pair, which will generally  make the communication flow over a different path.

I am a little puzzled by this concern. In a conventional multihoming situation
where BGP4 routing changes, we get an unplanned and unexpected path change,
and TCP deals with it as best it can. As far as TCP is concerned, shim6 is
the same - an unexpected path change. On the "first do no harm" principle,
shim6 can do exactly the same as BGP4 multihoming - nothing.

Sending a "path change" warning to TCP would be a nice-to-have feature,
but isn't an immediate requirement IMHO.

     Brian

Delivery-date: Thu, 14 Dec 2006 18:49:34 +0000
Date: Thu, 14 Dec 2006 16:36:06 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: Congestion issue [Re: shim6-proto-07 review]

Iljitsch van Beijnum wrote:
> On 14-dec-2006, at 14:31, Brian E Carpenter wrote:
> 
>> I am a little puzzled by this concern. In a conventional  multihoming 
>> situation
>> where BGP4 routing changes, we get an unplanned and unexpected path  
>> change,
>> and TCP deals with it as best it can. As far as TCP is concerned,  
>> shim6 is
>> the same - an unexpected path change. On the "first do no harm"  
>> principle,
>> shim6 can do exactly the same as BGP4 multihoming - nothing.
> 
> 
> The scale of shim multihoming is potentially quite different than  that 
> of BGP multihoming that we have today. Presumably, in a current  setup, 
> the amount of backup bandwidth is such that any congestion  after a path 
> change is survivable. On the other hand, the shim allows  many more 
> people to multihome, including single hosts that may have  both very 
> fast and very slow links. For instance, my laptop has a 1  Gbps 
> interface and a 9600 bps interface, five orders of magnitude.  With BGP, 
> I've never even seen two.

Understood, but this won't break TCP will it? So while this
is a longer term concern, I don't see why we need to deal with
it now. We could usefully document that we are not dealing with it.

    Brian

Delivery-date: Thu, 14 Dec 2006 14:02:18 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: Congestion issue [Re: shim6-proto-07 review]
Date: Thu, 14 Dec 2006 14:59:30 +0100
To: Brian E Carpenter <[email-masked]>

On 14-dec-2006, at 14:31, Brian E Carpenter wrote:

> I am a little puzzled by this concern. In a conventional  
> multihoming situation
> where BGP4 routing changes, we get an unplanned and unexpected path  
> change,
> and TCP deals with it as best it can. As far as TCP is concerned,  
> shim6 is
> the same - an unexpected path change. On the "first do no harm"  
> principle,
> shim6 can do exactly the same as BGP4 multihoming - nothing.

The scale of shim multihoming is potentially quite different than  
that of BGP multihoming that we have today. Presumably, in a current  
setup, the amount of backup bandwidth is such that any congestion  
after a path change is survivable. On the other hand, the shim allows  
many more people to multihome, including single hosts that may have  
both very fast and very slow links. For instance, my laptop has a 1  
Gbps interface and a 9600 bps interface, five orders of magnitude.  
With BGP, I've never even seen two.

Delivery-date: Thu, 14 Dec 2006 10:03:52 +0000
Cc: [email-masked]
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: comments on draft-ietf-shim6-proto-05.txt {3}
Date: Thu, 14 Dec 2006 11:02:08 +0100
To: Deguang Le <[email-masked]>

catching up with old email...

El 30/11/2006, a las 20:34, Deguang Le escribió:

> Hi Marcelo,
> I am sorry for my late response.
> Thanky you very much!
> See my comments inline... :-)
>
> marcelo bagnulo braun schrieb:
>
>> Hi Deguang,
>> El 15/10/2006, a las 15:24, Deguang Le escribió:
>>> Hi all,
>>> a slight comment on the Context Tag...
>>>
>>> -Page50
>>>    o  The context tag used to transmit control messages and payload
>>>       extension headers - allocated by the peer; CT(peer)
>>> -Page51
>>>    o  The context to expect in received control messages and payload
>>>       extension headers - allocated by the local host; CT(local)
>>>
>>> In page 50 and 51, two parameters, namely CT(peer) and CT(local), 
>>> are defined for each ULID-pair context. right?
>>>
>>> However, in page 13, the terminology of CT is given as follows:
>>>    Context tag         Each end of the context allocates a context 
>>> tag
>>>                        for the context.  This is used to uniquely
>>>                        associate both received control packets and
>>>                        payload extension headers as belonging to the
>>>                        context.
>>>
>>> Based on my understanding of above CT terminology, for a given 
>>> context, there is only "A" unique context tag used to identify the 
>>> context (i.e. the ULID-pair context, right?).
>>>
>> no, the above terminology states that _each_ end of the context 
>> allocates one context tag. since there are two ends in a shim 
>> context, this sums two context tags, right? CT(peer) and CT(local)
> You are right.
> Thank you very much! I think I understand what the two CTs means and
> their usages now.
> You mean each established shim6 context is identified by two CTs (i.e. 
> a
> peer CT and a local CT) in fact, and the values of these two CTs are
> different. Right? :-)
>
> However, I wonder why two endpoints can not negotiate "a" CT to
> establish and identify a shim6 context. Is it not feasible to establish
> a shim6 context if only "one" CT is used for identifying a context?
>

it would be possible of course, but i think it will be more 
difficult....

one option would be create the CT as the concatenation of both CTs, sso 
it would be easy to guarantee the uniquenes, but the price is that the 
CT lenght is the double, right?

the other option is to negotiate a CT, making one end to propose a CT 
and the other end verifying that it is good for him. In this case the 
additional cost comees from the negotiation phase.

So, in brief, it is possible to have a single CT but is has an 
additional cost, either on CT length or in negotiation steps, but the 
question is what do you want this for? what does this provides?

regards, marcelo

> Cheers,
> Deguang
>
>
>
>> Regards, marcelo
>>> Therfore, I am confused why each ULID-pair context needs these "TWO" 
>>> context tags: CT(peer) and CT(local)? Are the CT(peer) and the 
>>> CT(local) the same thing (or are they the same 47-bit number?)in 
>>> essence?
>>>
>>>
>>> Have a nice weekend!
>>> Cheers,
>>> Deguang
>>>
>>>
>>>
>>>
>>>
>
>
>

Delivery-date: Tue, 12 Dec 2006 13:50:32 +0000
Date: Tue, 12 Dec 2006 14:47:50 +0100
From: Matthijs Mekking <[email-masked]>
To: [email-masked]
Subject: teardown of the ULID-pair context

Hi,

I have a question about the teardown of the ULID-pair context. In
chapter 9, the proto6 draft says "A reasonable approach would be not to
tear down a context until at least 5 minutes have passed since the last
message was sent or received using the context." Does this include
messages that do not contain a shim6 extension header? My opinion is yes:

If there is a context on host A for host B, this means that both are
multihomed. They should enjoy the goals of multihoming, such as
failover. However, the communication between A and B initially uses the
ULID address pair. Therefore, the IPv6 address fields do not need to be
replaced by a different locator pair, and the message is not tagged with
a shim6 extension header. In other words, the context is not being used
at the moment. This means that if after 5 minutes there was no context
switch, the context states may be teared down again. If shortly after
this the link corresponding to the ULID pair fails, the hosts are not
able to do failover anymore.

So, shim unaware payloads (traffic not using the context) should also be
observed. I suggest that the text 'using the context' in chapter 9 will
be removed.

In order to observer shim unaware payloads, the shim6 layer should look
up a context for these kind of messages. Chapter 11 already defines how
this should be done for sending ULP payloads. For receiving packets
(chapter 12), this information is missing. I suggest there should be a
section before 12.1 receiving payload extension headers:

12.x Receiving payload without extension headers

The receiver extracts the IPv6 source and destination fields, and uses
this to find a ULID-pair context, such that the IPv6 address fields
match the ULID(local) and ULID(peer). If such a context is found, the
context appears not to be quiescent and this should be remembered. The
host continues with proceeding the message.

With regards,

Matthijs Mekking
[email-masked]
NLnetLabs/Radboud University

Delivery-date: Mon, 11 Dec 2006 18:56:21 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: shim6-proto-07 review
Date: Mon, 11 Dec 2006 19:54:04 +0100

(Note that I'm behind on the shim6 list so I'm not aware of recently  
discussed issues, so these may be duplicated here.)

This is a review of the shim proto 07 draft. It contains both nits  
and more fundamental issues, they are presented in the order of the  
text, but let me get two other things out of the way first:

1. Always including the context tag

As I've said many times, it's a very bad idea to unnecessarily  
increase overhead. Not only is this a bad thing in and of itself, but  
it also doesn't help convince people to forego IPv4+BGP in favor of  
IPv6+shim.

Now if we only include the shim header containing the context tag  
after a failure, this could be a reasonable tradeoff. However, I'm  
quite sure that if and when shim6 is adopted, some people will use it  
to manage their traffic engineering by doing a locator change  
immediately and proceed in a shimmed state for the rest of the  
communication session.

Earlier, I proposed to include a mandatory way for a host to instruct  
its peer to not include the shim header, pending mechanisms to do  
demultiplexing without the context tag. After reading the draft, I  
realize that this imposes some extra ICMP demultiplexing difficulties  
on implementations. So if the wg doesn't want to include this  
mandatory option, I suggest something different: since the traffic  
engineering mechanisms aren't really developed anyway and this  
problem is related to that, simply remove the locator preferences  
mechanism so that the context tag suppression can be included when  
proper traffic engineering is added.

Also see draft-van-beijnum-shim6-suppress-header-00.txt (do it while  
you can, it expires next week...), this outlines a more fully formed  
mechanism to suppress the context tag header.

I would very much like to see a consensus call on this subject.

2. Congestion

There is no discussion of congestion issues when the shim moves  
ongoing communicaiton to another locator pair, which will generally  
make the communication flow over a different path. We've had some  
discussions about this before, where the suggestion was made to go  
into slow start after a rehoming event. The counter argument: but  
maybe the new path is just as fast as the old one. My counter counter  
argument: suppose a file transfer over a 1 Gbps link, the Gbps link  
goes down and the session is rehomed to a low speed link (GPRS,  
modem, ADSL with limited uplink capacity). The send window used when  
the session went along over the Gbps link will be so large that  
massive congestion ensues, and also, all buffers will be filled up  
which guarantuees that the congestion will persist for a relatively  
long time, possibly a handful of seconds.

There are no easy answers here, but congestion control is one of the  
core concerns in the development of the internet, so I don't think we  
can get away with ignoring this completely.

    o  Preserve established communications in the presence of certain
       classes of failures, for example, TCP connections and UDP  
streams.

Shouldn't this be "communication"?

    o  Have minimal impact on upper layer protocols in general and on
       transport protocols in particular.

And applications.

Early in the text, the phrase "site multihoming" is used. There has  
been some discussion on this list as to whether shim6 actually is  
site multihoming, and readers of the draft may not know that all of  
this is the result of wgs chartered to work on "site" multihoming. So  
I suggest adding text to clear up any potential confusion, for example:

"The shim protocol is a site multihoming solution in the sense that  
it allows existing communication to continue when a site that has  
multiple connections to the internet experiences an outage on a  
subset of these connections or further upstream. However, shim  
processing is performed in individual hosts rather than through site- 
wide mechanisms."

    Finally, this proposal also does not try to provide a new network
    level or transport level identifier name space distinct from the
    current IP address name space.

The terms "identifier" and "locator" are used extensively even though  
the shim is NOT an actual identifier/locator separation solution...  
Suggested text (immediately following the sentence above):

"The shim proposal doesn't fully separate the identifier and locator  
functions that have traditionally been overloaded in the IP address.  
However, throughout this document the term "identifier", or more  
specifically, Upper Layer Identifier (ULID) refers to the identifying  
function of an IPv6 address, and "locator" to the network layer  
routing and forwarding properties of an IPv6 address."

    solution.  While this document doesn't specify all aspects of this,
    it is believed that the approach can be extended to handle the non-
    routable address case..

Extra period. (Note that the quaint custom of inserting an extra  
space after a sentence is generally "discouraged" in style manuals.)

    the original locators become invalid at the same time and depending
    on the time that is required to update the DNS and for those updates
    to propagate.

Why is the DNS relevant here?

    But IP addresses are also used as ULID,

Addresses is plural, ULID singular... Probably make this "ULIDs".

    In the worst case we could end up with two separate hosts using the
    same ULID while both of them are communicating with the same host.

    This potential source for confusion is avoided requiring that any
    communication using a ULID MUST be terminated when the ULID becomes
    invalid (due to the underlying prefix becoming invalid).

This makes me uncomfortable. How do you know that an address has  
become terminally invalid, rather than accidentally unusable? I  
contend that the distinction can't be made in a stack in a meaningful  
way, so the above requirement will in practice only serve to disrupt  
communication unnecessary. Rather, I would require some  
administrative "cooling off" period to avoid using the same ULID by a  
different host (only possible with CGA not HBA anyway). For instance,  
there must be 24 hours between decommisioning and recommisioning of  
address space, and we garbage collect shim state after 24 hours of  
not being used.

I don't see how regular nomadic behavior will result in two hosts  
using the same address in quick succession, and they can further  
reduce the potential for problems by not using temporary addresses as  
ULIDs.

    layer map to/from different locators.  The shim6 layer maintains
    state, called ULID-pair context, per ULID pairs

"Pairs" should probably be singular.

    fields, and even though those locators may be changed by the
    transmitting shim6 layer. .

Extra  .

    The result of this consistent mapping is that there is no impact on
    the ULPs.  In particular, there is no impact on pseudo-header
    checksums and connection identification.

The problem here is that some intermediate system, such as a firewall  
or a smart NIC, may take it upon itself to check the TCP or UDP  
checksum and discard the packet if the checksum fails. For firewalls  
and the like, the best thing is probably either to fully monitor the  
shim state so they can do this properly, or forego such checking if a  
shim header is present.

For NICs a better solution would be to do an incremental checksum  
verification and only over the ULP segment, so that the host stack  
must complete the calculation by applying the increment from the  
pseudo header, which can largely be cached, so the performance  
advantages are almost completely preserved

    Inherent in a scalable multihoming mechanism that separates locators
    from identifiers is that each host ends up with multiple locators.

This says explicitly that we do id/loc...

    This means that at least for initial contact, it is the remote peer
    that needs to select which peer locator to try first.  In the  
case of
    shim6 this is performed by applying RFC 3484 address selection.

This is incorrect: the application (or layer working on its behalf)  
needs to select an initial ULID, which automatically becomes the  
initial locator.

    This document uses the terms MUST, SHOULD, RECOMMENDED, MAY, SHOULD
    NOT and MUST NOT defined in RFC 2119 [1].  The terms defined in RFC
    2460 [2] are also used.

Please list them.

    FQDN                Fully Qualified Domain Name

Hm, if you don't know what FQDN is you probably also don't know what  
it is when spelled out... How about adding "full DNS name"?

    document), such as having the ISPs relax there ingress filters, or
    selecting the egress such that it matches the IP source address
    prefix.

There -> their

    o  Some heuristic on A or B (or both) determine that it is
       appropriate to pay the shim6 overhead to make this host-to-host
       communication robust against locator failures.  For instance,  
this
       heuristic might be that more than 50 packets have been sent or
       received, or a timer expiration while active packet exchange  
is in
       place.  This makes the shim initiate the 4-way context
       establishment exchange.

Maybe say something like:

"The purpose of this heuristic is to avoid setting up a shim context  
when only a small number of packets is exchanged between two hosts."

       If the context establishment exchange fails, the initiator will
       then know that the other end does not support shim6, and will
       continue with standard unicast behavior for the session.

Unicast? Shouldn't this be "single homed"?

    the message allocated.  Thus at a minimum the combination of <peer
    ULID, local ULID, local context tag> have to uniquely identify one
    context.

I'm not sure if I understand this.

More in general, the draft seems to suggest that the content of the  
source address field in received packets may be ignored, but also  
that this is not the case. This is a very important decision with far  
reaching consequences so it should be made carefully. For instance,  
if the source address may be rewritten arbitrarily, obviously routers  
can easily do this without much or any coordination. But the  
potential for security issues is significant in this case.

    context.  But since the Payload extension headers are demultiplexed
    without looking at the locators in the packet, the receiver will  
need
    to allocate context tags that are unique for all its contexts.

See above.

    context tag is a 47-bit number (the largest which can fit in an
    8-octet extension header).

"while preserving one bit to differentiate the shim signalling  
messages from the shim header included in data packets, allowing both  
to use the same protocol number."

4.2 context forking

Never been a fan of this, but it doesn't seem to add too much extra  
complexity the way it is now.

       Such discovery probably requires to be along the path in order to
       be sniff the context tag value.

Grammar: clause without subject. Who is required to be along the path?

    dynamic.  For this reason there is a Update Request and Update
    Acknowledgement messages, and a Locator List option.

Grammar. "is a" -> "are" would be better.

    Even when the list of locators is fixed, a host might determine that
    some preferences might have changed.  For instance, it might
    determine that there is a locally visible failure that implies that
    some locator(s) are no longer usable.  This uses a Locator
    Preferences option in the Update Request message.

I don't consider reachability status a preference...

    Bidirectional Communication (FBD).  FBD uses a Keepalive message
    which is sent when a host has received packets from its peer but has
    not yet sent any packets from its ULP to the peer.

No, this works per address (per locator even, not per ULID, IIRC),  
not per ULP.

    which precedes a routing header).  When tunneling is used, whether
    IP-in-IP tunneling or the special form of tunneling that Mobile IPv6
    uses (with Home Address Options and Routing header type 2), there is
    a choice whether the shim applies inside the tunnel or outside the
    tunnel, which affects the location of the shim6 header.

How is this coordinated with the other side? If one side does  
tunneling first and shim second and the other side the other way  
around, there will be trouble. I don't see an easy way to avoid this.

    the control messages; only the payload extension header use the Next
    Header field.

uses

    Next Header:   8-bit selector.  Normally set to NO_NXT_HDR (59).

So what happens when some other header follows the shim header? Could  
this be used for attacks?

About the different messages: they are very similar. If I were to  
implement all of this, I would rather work with one basic structure  
for all of the messages, even if the _meaning_ of some fields is  
different as long as their structure is always the same. I think this  
can easily be done here, by including fields that nearly all messages  
need (simply leave it zero when a particular message doesn't need a  
field) and use options for things that a particular message needs  
that aren't accommodated in the unified structure.

Did I miss the place where HBA information is exchanged?

update request: why is this a request?

    This message is sent in response to a Update Request message.  It
    implies that the Update Request has been received, and that any new
    locators in the Update Request can now be used as the source  
locators
    of packets.  But it does not imply that the (new) locators have been
    verified to be used as a destination, since the host might defer the
    verification of a locator until it sees a need to use a locator as
    the destination.

Hm, is it smart to defer verification here? We've already said that  
the other end may use them as source addresses. If there is a failure  
and we do the verification then, we may find out that it fails and we  
have no reasonable course of action.

Also, for CGA verification, don't we need to send the other side a  
challenge to avoid replays?

    direction.  When the ULP is sending bidirectional traffic, no extra
    packets need to be inserted.

This works per address pair, not per ULP.

5.13.  Probe Message Format

    This message and its semantics are defined in [9].

    The idea behind that mechanism is to be able to handle the case when
    one locator pair works in from A to B, and another locator pair  
works
    from B to A, but there is no locator pair which works in both
    directions.  The protocol mechanism is that as A is sending probe
    messages to B, B will observe which locator pairs it has received
    from and report that back in probe messages it is sending to A.

No, this is to test whether locator pairs work or not in the general  
case.

    All of the TLV parameters have a length (including Type and Length
    fields) which is a multiple of 8 bytes.

Ugh, this is certainly enough to make a grown man cry... Why all of  
this alignment silliness? BGP works pretty well without it.

    Consequently, the Length field indicates the length of the Contents
    field (in bytes).  The total length of the TLV parameter (including
    Type, Length, Contents, and Padding) is related to the Length field
    according to the following formula:

    Total Length = 11 + Length - (Length + 3) % 8;

This is almost impossible to understand.

First of all, this assumes familiarity with C or a similar language  
from the reader to note that % is the modulo operation and that it  
binds stronger than subtraction. As such, this would be an improvement:

Total Length = 11 + Length - ((Length + 3) mod 8)

However, the logic that underpins this is never spelled out, apart  
from the requirement that all options be a multiple of 8 bytes long.  
(Yes, _bytes_, not octets.)

Text:

"The Total Length of the option is the smallest multiple of 8 bytes  
that allows for the 4 bytes of option header and the option itself.  
The amount of padding required can be calculated as follows:

padding = 7 - ((Length + 3) mod 8)

And:

Total Length = 4 + Length + padding"

I see no discussion of size issues. A single option can be made large  
enough to push a packet beyond 1280 bytes. More realistically, this  
will happen when multiple options are present. What happens in this  
case? What is the largest option size and the largest shim packet  
size implementations must be prepared to handle?

    C:             Critical.  One if this parameter is critical, and  
MUST
                   be recognized by the recipient, zero otherwise.

You can't force a receiver to recognize something...

    o  If C=1 then the host SHOULD send back an ICMP parameter problem
       (type 4, code 1), with the Pointer referencing the first octet in
       the option Type field.  When C=1 the message MUST NOT be
       processed.

Why use ICMP for errors? Isn't it easier to define a shim error  
message? If the correspondent wants to fall back to some other way to  
set up the shim having to intercept ICMP messages to make that happen  
is pretty messy.

More in general, most error conditions are handled by silently  
dropping packets, however, which is a very bad idea because that way,  
there is no difference between an error and lost messages. So in some  
cases, a host may continue to resend the offending packet because it  
doesn't know something went wrong. The main problem with this  
approach is that you can't debug it from one end: you need to see  
what happens on both ends to determine why something doesn't work.

Silently dropping packets because of errors is the right approach for  
security reasons in some cases, but I don't think this applies here.  
A short error message with an error code and optionally a human- 
readable message would be much better. As long as these error packets  
are smaller than the packets that trigger them, there should be  
little or no security impact, especially considering that we're  
prepared to talk shim with the correspondent in question to begin with.

    The responder can choose exactly what input is used to compute the
    validator, and what one-way function (MD5, SHA1)

Or something else, I presume? So "(such as MD5 or SHA-1)"

About the locator option: how many locators are allowed?

       TEMPORARY: 0x02

    The intent of the BROKEN flag is to inform the peer that a given
    locator is known to be not working.  The intent of TEMPORARY is to
    allow the distinction between more stable addresses and less stable
    addresses when shim6 is combined with IP mobility, when we might  
have
    more stable home locators, and less stable care-of-locators.

So this has nothing to do with RFC 3041 temporary addresses? In that  
case, a different name is probably better.

    o  For each peer locator, a bit whether it has been verified using
       HBA or CGA, and a bit whether the locator has been probed to
       verify that the ULID is present at that location.

"Flag" rather than "bit"?

    | E-FAILED            | Context establishment exchange failed

How do we know this, and is it necessary to explicitly take notice of  
this situation?

    | E-FAILED            | ULID(peer), ULID 
(local)                     |
    |                      
|                                             |
    | NO-SUPPORT          | ULID(peer), ULID(local)

How is ULID(local) relevant here? We know there is connectivity (ULP  
is running) so if we don't get any shim negotation back or it fails,  
then this situation can be attributed to the peer as a whole, not to  
the ULID pair.

    In all the cases the result is that the peer without state  
receives a
    shim message for which it has to context for the context tag.

To -> no?

    case we can not use the recovery mechanisms since there needs to be
    separate context tags for the two ULID pairs.

Needs -> need

Regarding section 7.9: shouldn't there be checks to make sure that  
seemingly duplicate packets contain the same information as the  
earlier packets they are supposedly the duplicate of?

What if validators don't match? Eventually this shouldn't be a  
problem but I expect some initial trouble here because you're doing  
hashes over a fairly large number of values, a small mistake  
somewhere means the hash doesn't work, some feedback in the form of  
an error message would be good.

It occurs to me that there is nothing or very little in the protocol  
that precludes shim negotiation using non-ULID addresses. We probably  
need a few minor tweaks to the reachability protocol to also allow  
this, but then there is no fundamental reason to not allow shim setup  
using non-ULID addresses, and by extension, unreachable ULIDs = a  
separate identifier space. If it's this easy, we should definately  
make sure there isn't some minor obstacle somewhere, so that we can  
add this feature easily in the future when we've worked out the  
additional issues such as locator discovery.

    o  Where Ls(peer) has at least one locator in common with the newly
       created or updated context.

Why? I don't see how that buys us anything. Also, it's fairly trivial  
to insert a bogus locator to meet the requirement that there is one  
in common between the old and new sets.

Adn why verify whether the source address is in Ls(peer)? The  
security mechanisms do all the checking we need.

       context.  In this case, we are in the Context confusion  
situation,
       and the host MUST NOT use the old context to send any  
packets.  It
       MAY just discard the old context (after all, the peer has
       discarded it), or it MAY attempt to re-establish the old context
       by sending a new I1 message and moving its state to I1-SENT.  In
       any case, once that this situation is detected, the host MUST NOT
       keep two contexts with overlapping Ls(peer) locator sets and the
       same context tag in ESTABLISHED state, since this would result in
       demultiplexing problems on the peer.

What if an attacker is trying to interfere with legitimate  
communication? We must be VERY sure that the new shim messages come  
from the same host as the one that created the existing state if  
we're going to mess with that existing state.

About the randomness of the context tag: I don't think we have to  
require that the entire context tag random in a cryptographically  
strong sense. If this makes implementation easier, why not allow an  
implementation to use part of the CT to be used as a lookup key  
(which is relatively easy to predict) as long as enough bits are  
really random? In my opinion, 20 good random bits is enough here.  
Suggested text (but no suggested place to put it):

"It is important that context tags are hard to guess for off-path  
attackers. Therefore, if an implementation uses structure in the  
context tag to facilitate efficient lookups, at least 20 bits of the  
context tag must be unstructured and populated by completely random  
bits. For this purpose, bits derived from one of the generally used  
one-way hash functions such as SHA-1 may be considered random.

    A host MUST silently discard any received Update Acknowledgement
    messages that do not satisfy all of the following validity checks in
    addition to those specified in Section 12.2:

    o  The Hdr Ext Len field is at least 1, i.e., the length is at least
       16 octets.

Added bonus when the header structure is unified: no need to repeat  
the above over and over throughout the text.

    NO_R1_HOLDDOWN_TIME = 1 min

    ICMP_HOLDDOWN_TIME = 10 min

This seems rather short, basically a shim host talking to a non-shim  
host would retry setting up the shim every minute or every 10 minutes  
even though there is good reason to assume this won't be successful.  
Something like several hours seems more appropriate. (And only when  
packets are actively exchanged.)

    network transit path.  Second, in case that IPSec is implemented as
    Bump-In-The-Wire (BITW) [7] it is expected that the shim6 sub-layer
    is also implemnted in the same fashion.

Not strong enough:

"in case that IPSec is implemented as Bump-In-The-Wire (BITW) [7],  
either the shim MUST be disabled, or the shim MUST also be  
implemented as Bump-In-The-Wire, in order to satisfy the requirement  
that IPsec is layered above the shim."

       could require a 2-way handshake "did you really loose the state?"
       in response to the error message.

lose

    o  The validator included in the R1 and R1bis packets are generated
       as a hash of several input parameters.  However, most of the
       inputs are actually determined by the sender, and only the secret
       value S is unknown to the sender.  However, the resulting
       protection is deemed to be enough since it would be easier for  
the
       attacker to just obtain a new validator sending a I1 packet than
       performing all the computations required to determine the secret
       S. However, it is recommended that the host changes the secret S
       periodically.

Too many howevers...

    o  Study whether a host explicitly fail communication when a ULID
       becomes invalid (based on RFC 2462 lifetimes or DHCPv6), or  
should
       we let the communication continue using the invalidated ULID (it
       can certainly work since other locators will be used).

Some kind of grammar problem, not obvious to me what is meant here.

Appendix B.  Simplified State Machine

    The states are defined in Section 6.2.  The intent is that the
    stylized description below be consistent with the textual  
description
    in the specification, but should they conflict, the textual
    description is normative.

Haven't looked at this.

    that the Flow Label carries context information as proposed in the
    now expired NOID draft. .

Extra  .

    It may happen, that later on, one of the hosts, e.g.  Host A looses
    the shim context.

loses

    Mechanisms for detecting context. loss

Extra word?

There are discussions in the appendixes, maybe make this a separate  
document?

The Locator List Option Format only specifies two verification  
methods at this time: CGA or HBA. What about the case where a locator  
can be verified using either CGA or HBA? Maybe it makes more sense to  
have each method be a bit so they can be present or absent  
independently.

    approach eliminates the possibility of a context confusion situation
    because premature garbage collection, but it does not prevents

prevent

    [9]  Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
         Exploration Protocol for IPv6  Multihoming",

Please make this "I. van Beijnum"

Note to self: look at implications of the fact that keepalive and  
probe messages (as defined here) don't trigger R1bis in the  
reachability draft.

Delivery-date: Mon, 11 Dec 2006 09:03:43 +0000
Date: Mon, 11 Dec 2006 10:02:07 +0100
From: Matthijs Mekking <[email-masked]>
To: [email-masked]
Subject: Retransmission of I2 messages

Hi,

I have a question about the proto draft. In section 7.12, the draft says
 "If the initiator does not receive an R2 message after I2_TIMEOUT time
after sending an I2 message it MAY retransmit the I2 message" and "Thus
the initiator SHOULD fall back to retransmitting the I1 message when
there is no R2 received after retransmitting the I2 message
I2_RETRIES_MAX times."

I am concerned about keywords MAY and SHOULD in section 7.12. If an
implementation decides not to implement these retransmissions, then
according to the protocol specification, the fall back to retransmitting
I1 messages would never occur (because this SHOULD happen after
I2_RETRIES_MAX retransmissions of I2). If the I2 is not accepted by the
responder, and no retransmissions are sent, than the context would stay
in I2-SENT, and is never able to reach ESTABLISHED.

I think the host MAY retransmit I2 messages, but MUST fall back after a
certain amount of time, to avoid this deadlock situation. The same
applies for retransmitting I2bis messages.

Furthermore, last week I have sent an e-mail with questions about the
proto6 draft (http://ops.ietf.org/lists/shim6/msg01738.html). I would be
very grateful if someone could answer them.

With kind regards,

Matthijs Mekking
[email-masked]
NLnetLabs/Radboud University

Delivery-date: Sun, 10 Dec 2006 22:28:11 +0000
Date: Mon, 11 Dec 2006 00:26:20 +0200
From: Jari Arkko <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>,  [email-masked]
Subject: Re: option for setting non-default Keepalive Timeout in REAP

Thanks for the text. I have merged this in, and
it will be a part of the -07 draft.

--Jari

Delivery-date: Thu, 07 Dec 2006 00:04:38 +0000
Date: Thu, 07 Dec 2006 11:02:45 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-proto-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

This draft is a work item of the Site Multihoming by IPv6 Intermediation Working Group of the IETF.

        Title           : Level 3 multihoming shim protocol
        Author(s)       : M. Bagnulo, E. Nordmark
        Filename        : draft-ietf-shim6-proto-07.txt
        Pages           : 124
        Date            : 2006-12-6
        
The SHIM6 protocol is a layer 3 shim for providing locator agility
   below the transport protocols, so that multihoming can be provided
   for IPv6 with failover and load sharing properties, without assuming
   that a multihomed site will have a provider independent IPv6 address
   prefix which is announced in the global IPv6 routing table.  The
   hosts in a site which has multiple provider allocated IPv6 address
   prefixes, will use the shim6 protocol specified in this document to
   setup state with peer hosts, so that the state can later be used to
   failover to a different locator pair, should the original one stop
   working.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-shim6-proto-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Delivery-date: Tue, 05 Dec 2006 13:56:51 +0000
Date: Tue, 05 Dec 2006 14:54:37 +0100
From: Matthijs Mekking <[email-masked]>
To: [email-masked]
Subject: questions about draft-ietf-shim6-proto-06.txt

Hello,

My name is Matthijs, and I am doing research on shim6 for Radboud
University Nijmegen/NLnetLabs Amsterdam (Netherlands). I have a couple
of questions about draft-ietf-shim6-proto-06.txt that seem a bit unclear
to me. Some of them are maybe obvious comments, but I shall make them,
because I think it is good for a protocol description to allow only one
clear interpretation.

1. Wat is exactly meant with VALIDATOR_MIN_LIFETIME? According to the
draft, "the peer might reject Responder Validator options that are older
than VALIDATOR_MIN_LIFETIME to avoid replay attacks" and "Nonces that
are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent".
Does this value apply to both nonces and responder validator options?

Is this value solely used by a host acting as responder?

If so, do you agree that this value should be used outside SHIM6?
Because a responder may not store state (yet) and thus can not verify if
a nonce in an I2 or I2bis message may be considered recent. If you
agree, can't this value be omitted from the document (since it is
independent of the correct working of SHIM6, but merely a security
consideration of the host)?

2. In addition, when generating a responder validator, the draft talks
abouot increasing a counter, and using the counter value as responder
nonce. Is this the same way how the responder and initiator computes
their other INIT nonces and RESP nonces?

3. In section 7.12, the host MAY retransmit I2. Why is this a MAY and
not a SHOULD?

4. The draft considers a context in state IDLE the same as a context
being non-existing. However, the state machine in appendix B says that
context in state E-FAILED of state NO-SUPPORT should behave the same as
if it was in IDLE. Does this mean when chapter 7 speaks of 'if no
context is found, the host should ... (do something useful)' this also
applies to if a context is found and the state is E-FAILED or
NO-SUPPORT? For example in section 7.9: "If no state is found (i.e., the
state is IDLE), then the host replies with a R1 message as specified
below." Does a host needs to reply with R1 if a context is found that is
in state E-FAILED or NO-SUPPORT?

5. In chapter 6, a conceptual model of the host is given. However, the
second table in section 6.2 introduces some new elements that are not
described in section 6.1: INIT nonce, RESP nonce and CT(R1bis). I
suggest that they (including a short description) are added to section 6.1.

6. Am I right that the RESP nonce in I2-SENT is stored so that the host
is able to create the correct I2 retransmission? If so, than the
responder validator should also be stored (because this is also copied
from the R1 message, just like RESP nonce). If this is the reason, than
I think RESP nonce, INIT nonce and the responder validator should also
be stored in state I2BIS-SENT.

7. In the text, computing a responder validator looks inconsistent with
generating the validator:

For R1 the secret S, the Initiator Context Tag and the locators are
omitted when computing the validator:

"use the following information concatenated as input to the one-way
function:
o  The the secret S
o  That Responder Nonce
o  The Initiator Context Tag from the I1 message
o  The ULIDs from the I1 message
o  The locators from the I1 message (strictly only needed if they are
different from the ULIDs)
o  The forked instance identifier if such option was included in the
I1 message"
(section 7.10.1, page 62)

and

"that the Responder Validator option matches the validator the host
would have computed for the ULID, locators, responder nonce, and FII."
(section 7.13, page 63).

For R1bis the secret S and Receiver Context tag are omitted when
computing the validator, but the ULID and FII are added:

"use the following information concatenated as input to the one-way
function:
o  The the secret S
o  That Responder Nonce
o  The Receiver Context tag included in the received packet
o  The locators from the received packet"
(section 7.17.1, page 68)

and

"the Responder Validator option matches the validator the host would
have computed for the ULID, locators, responder nonce, and FII as part
of sending an R1bis message."
(section 7.20, page 69)

With kind regards,

Matthijs Mekking
[email-masked]
NLnetLabs/Radboud University