[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shim6-proto-07 review
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.