On 28-dec-2006, at 18:58, marcelo bagnulo braun wrote:
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?
Thinking a bit more about this, I keep coming back to TCP slow start...
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...
Hm, isn't the word "communication" like "water"? I.e., you don't have
several of it, it's just one thing of which you have more or less.
"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?
Maybe "placement of the shim", "terminology" or even "introduction"?
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?
I don't understand what you mean here... The way I see it, the stuff
that's in the DNS doesn't change when there are outages, only when links
are added to or removed from the site. As such, the DNS timing is
irrelevant except in the corner case where all existing links are
replaced by all new ones or all the links that don't change go down.
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?
Indeed. The autoconfig protocols don't have a mechanism to see the
difference between a router going down accidentally and administrative
removal of prefixes, unless you want to add significant amounts of
guesswork to the mix. And that's something I don't think is a good idea,
especially considering that in SITE multihoming the chances of clashing
ULIDs after renumbering are near-zero.
what about when the address becomes invalid?
In many Unix stacks you can keep using an address even if it's removed
from all interfaces. This is a good thing, because it allows sessions to
survive short transitions such as moving out of radio range for a few
moments. With shim6 there is the potential that the address is gone for
a long time but it remains in use because the failure is repaired using
the shim.
I think the best thing to do here is keep using the address for a
limited amount of time, like 1 - 24 hours.
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...
Of course not. A site administrator can't reach out into the state
inside all the hosts in the site...
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.
Right. So don't use this type of addresses as ULIDs and then there are
no problems.
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?
Ok.
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
Hm, this makes me uncomfortable... As a receiver, I would much rather
know in advance which source addresses I'm going to see for established
sessions/context.
Also, the source address can't be changed arbitrarily because then ICMP
messages don't make it back to the source.
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?
I don't know. In general, I'm not all that paranoid about security so
I'm not really the person to ask if security is good enough. :-)
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?
No, because I don't see what the ULP has to do with anything. FBD is
between address pairs.
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?
Ok I don't see how it fails so I'll take your word for it...
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
Well, wouldn't it be better then to forbid having additional headers
after the shim header?
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?
When you write an implementation, you need to extract all the values
from a header. Since these are all different sizes without natural
alignment this involves some complexity. When there are different
message headers, you need to do this multiple times. If there is only
one message header, you only have to implement the value extraction code
once.
The field names aren't an issue at all. In code it works something like
this:
void getheaders(int *field1, char *field2, unsigned int *field3);
void lookatmessage1()
{
int contexttag;
char evilbit;
unsigned int remotecookie;
getheaders(&contexttag, &evilbit, &remotecookie);
if (evilbit)
printf("You are breaking Evil Corp.'s patent, prepare to be sued!\n");
}
void lookatmessage2()
{
int contexttag;
char ossbit;
unsigned int localcookie;
getheaders(&contexttag, &ossbit, &localcookie);
if (!ossbit)
printf("You are breaking the GPL, prepare to be sued!\n");
}
Since the formats are so similar already there are only 1 or 2 cases
where an unused field would be included so I don't think the overhead is
a concern.
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?)
Just "update"?
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?
Is it useful to be able to defer locator verification? Simply doing it
immediately and either acknowledging that everything is ok or sending
back an error is much more robust than saying nothing and failing later.
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?
No, it's still confusing. Why not leave this up to the reachability draft?
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...
Believe me, implementations aren't going to be any simpler because of
all the padding and length calculations, and the amounts of data
involved are so small that having faster copying because of the
alignment isn't an issue.
[...]
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.
[...]
sent this issue in a separate email
IIRC this mail doesn't go into the issue of silently dropping messages,
so I'll restate my objection to that here.
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
Some limit might be helpful, though.
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"?
Sure.
| 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?
I prefer to have as few states as possible, but if you think having a
separate state here is helpful, I guess it isn't really harmful.
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
So the issue whether it's a duplicate is irrelevant because the reply is
the same either way?
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?
If you have special case handling for duplicates it's important to be
sure that you're actually dealing with duplicates. For instance, an
attack could be sending out fake shim6 packets so that when the real
ones come in later, those are rejected because they are presumed
duplicates.
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...
Initial = when implementations first appear.
It's important that people know what's going on in order to debug
problems, not only when doing interoperability testing, but also "in the
wild" later on.
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....
In the case of unreachable ULIDs where the shim packets use locator
source/destination addresses.
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)
Good.
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...
Page 59:
If such a context exists in ESTABLISHED state, the host verifies that
the locator of the Initiator is included in Ls(peer) (This check is
unnecessary if there is no ULID-pair option in the I1 message).
Page 63:
o If the state is I1-SENT, then the host verifies if the source
locator is included in Ls(peer) or, it is included in the Locator
List contained in the the I2 message and the HBA/CGA verification
for this specific locator is successful
Page 69:
o If the state is I1-SENT, then the host verifies if the source
locator is included in Ls(peer) or, it is included in the Locator
List contained in the the I2 message and the HBA/CGA verification
for this specific locator is successful
o If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host
verifies if the source locator is included in Ls(peer) or, it is
included in the Locator List contained in the the I2 message and
the HBA/CGA verification for this specific locator is successful
Page 74:
Since context tags can be reused, the host MUST verify that the IPv6
source address field is part of Ls(peer) and that the IPv6
Page 76:
Since context tags can be reused, the host MUST verify that the IPv6
source address field is part of Ls(peer) and that the IPv6
destination address field is part of Ls(local).
Page 81:
o Other control messages (Update, Keepalive, Probe): Deliver to the
context with CT(local) equal to the Receiver Context Tag included
in the packet. Verify that the IPv6 source address field is part
of Ls(peer) and that the IPv6 destination address field is part of
Ls(local). If not, send a R1bis message.
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
The case where a firewall silently filters the packets is much more
likely. I still find what you list above rather short.
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?
I guess you can argue that if HBA verification is possible, there is
never a need to do CGA verification.
Still, I think having bits for this rather than a single code is good
for two reasons:
1. In case someone wants to implement either HBA or CGA but not both for
IPR reasons, then it becomes useful to announce both HBA and CGA capability
2. So that when in the future a new verification method is introduced
that obviously isn't universally implemented but is better than CGA/HBA
in some way, so that people may want to take advantage of the new method
when supported but fall back on HBA/CGA if not
Please make this "I. van Beijnum"
will try if the xml tool allows me to....
Please make sure this goes out correctly when it becomes an RFC.