[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.