[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: about draft-ietf-shim6-proto-01.txt




El 18/10/2005, a las 22:22, Erik Nordmark escribió:

marcelo bagnulo braun wrote:
Hi,
i think that the document is improving rapidly, i send some comments below...

Thanks for your comments.

I've addressed the comments if they are not included in this response.
Thus I'm just responding with clarifications and discussion points here.

In section 2.1  Definitions
Host-pair context The state that the multihoming shim maintains for
                       a particular peer.  The context is for a ULID
pair, as is identified by a context tag for each
                       direction.
I would rather use the expression shim-context rather than host pair context, because since each context is associated to a given ULID pair, there maybe more than one context for a given host pair, right?

If we've nailed that down it might make sense to rename it ULID-pair
context.

agree

A "shim context" name doesn't indicate much about its scope.


right, that is why this would a good name even if we haven't nailed it down :-)

But I'm not sure we've nailed that down completely; there might be some
sharing of reachability state across different ULID-pairs for the same
host-pair.


ok we can wait and see later

(moreover, as we consider the forking concept more in depth, there maybe more than one context for a given ulid pair) so using the vague expression shim context would suit to whatever extent this evolves to.

But even with forking one context applies to only one ULID-pair. (Having
multiple contexts per ULID pair doesn't change this.)


agree, the point was against host pair context terminology. I agree that ulid pair context terminology is ok here too


   Even though we do not overload the flow label field to carry the
   context tag, any protocol (such as RSVP or NSIS) which signals
   information about flows from the host stack to devices in the path,
need to be made aware of the locator agility introduced by a layer 3
   shim, so that the signaling can be performed for the locator pairs
   that are currently being used.
I would remove the first part of the sentence of this paragraph. I mean, in the future when people read the spec, they won't be familiar with our flow label discussions, so this initial part of the sentence may sound a bit strange to them imho.

Well, yes, but I'm more concerned about people understanding it now
since we've changed direction a bit on this point. We can adjust this
later (as in -03).


fine

and then the payload and control messages can be defined.
Then in section 5.2  Common Shim6 Control header
The common part of the header has a next header and header extension
   length field which is consistent with the other IPv6 extension
headers, even if the next header value is always "NO NEXT HEADER" for
   the control messages
but before this header there can be other header, right? like the routing header or hop-by-hop header.
My point is that this header is also located before
   any endpoint extension headers (fragmentation headers, destination
options header, AH, ESP), but after any routing related headers (hop-
   by-hop extensions header, routing header, a destinations options
   header which precedes a routing header).
The difference is that for now, no piggybacking of ulp in the shim control messages is defined yet.

And none planned! ;-)
We know from MIPv6 endless discussions that piggybacking e.g. TCP
payload on some other semantics carrying protocol is problematic, since
since like packet policies (IPsec, firewalls) might want to let one part
of the packet through and not another part of it.


ok, i wasn't aware that this was the problem

So i would state the location of the shim header and distinguish the case of payload messages where piggybacking of ulp is supported and control messages, where it is not. This description would fit in the description of the common header (since it is always placed in the same place)

I don't understand what text you are suggesting to change, given that we
do not allow anything but nexthdr=59 for control messages.


no problem, i will wait to see how the result of the previous changes so that probably this won't be an issue for me anymore

In section 5.4  R1 Message Format
It may make sense to allow the responder to include the locator set in the R1 message, so that the initiator can acknowledge the reception of the locator set (otherwise, the locator set of the responder is sent in R2 which remains unacknowledged).

This isn't a problem AFAICT. If the initiator doesn't receive R2 it will
retransmit I2. The ULP packets from responder to initiator can still
flow, since they haven't failed over to use an alternate locator pair
yet.

right

 Worst case would be a packet loss when we want to switch to
alternate locators immediately as part of the context establishment
(when the responder might start sending payload messages before the
initiator has received the lost R2.)


yes, but this would also be covered by the context loss recovery mechanism that is being considered, right? i mean, the peer could reestablish the context with an alternative locators (and the same ulids)

If we want to fix that, it might make more sense to make the receiver
demux packets solely on the context tag, thus the source locator isn't
used to lookup the context state. (This also allows router rewriting of
source locators, which might be useful flexibility for the future.)


the potential problem with this is that an small I1 packet may result in a somehow big R1 packet which may be used by an attacker as an amplifier (but i am not sure whether this is a big issue, since the amplification won't be so important)

If you are going to send the locator list, wouldn't you need to also
send that is needed by the peer to verify the list? For CGA that would
imply generating a PK signature in order to send R1.


actually this depends on what is being signed.
one possiblity is that the responder signs the locator list (without any context specific information). In this case, the responder doesn't need to sign the locator list each time it sends a R1, resulting in less processing. the questions that are open here are reply attacks and if we need to sign also the locator list version...

...
Either the host needs to track that it has an old (potentially still
unverified) list of locators from the context establishment, and a new
(unverified) list of locators from one (or more) update messages, and
accept any one of those locators as a source.


but this would imply that a host would need to keep track of all the locators that once were available for the context, which would potentially imply a much larger memory consumption than it would require to just keep track of the current locator list

Or, we bite the bullet and have a larger context tag and ignore the
source locator in the lookup.

But in both cases we have an issue with injection of bad Update
messages. What prevents the on-path attacker from injecting such a
message and replacing the CGA parameter set with something, which when
verified, will fail the verification?

nothing, but in this case we can detect that the message was false and keep the last locator list that was verified

I think this problem is quite interesting indeed
to summarize:
Threats involved in accepting packet from unverified sources (this apply both to using only the context tag to demux and to defer locator list validation until we need to send packets to the locator)

1- time shifted packet injection attack. This would allow an attacker that were once on path and learned the context tag, to inject packets as into a communication associated with a shim context. The difference with current (non-shim) environment is that today the attacker needs to use a topologically correct address to be able to spoof the source address and inject packets into a communication. In the new context with the shim, the attacker doesn't even need to by pass ingress filters since it can simply send with its own source address and the shim will replace it with the ULID used in the shim context.

2- Stalled locator list. (DoS attack) An attacker can update the locator list with a new list of invalid locators, so that the victim won't be able to accept any packets (if the source address is verified)


others threats?

Possible solutions:
- use only the context tag for demux: deal with issue #2 but not with issue #1 - keep a record of all previous locators: deal with issue #2 but not with issue #1 (higher memory consumption) - verify the locator list using hba/cga: deals with both of them, but imposes cpu consumption up front (even if we never need the alternative locators)





In section 5.14.3  Locator Preferences Option Format
I am not sure i fully understand the format of this option...
For instance, all elements have the same length i.e. the Element length field message applies to all the elements

Yes.

, or there is an Element Length
field for each Element item that follows? (i think it is the first option, but the figure confuses me, because the Element[2] seems to have a different Length than Element[1] and Element[3]; other thing that confuses me about the figure is that the Element Length field seems to have variable length or 2 octets (because it has two rows))

The picture was messed up a bit, but all the Elements are two octets in
it. Perhaps I need a different picture for each different Element Len?


Well, that would make it really clear but maybe it would be too much.
One option would be to depict one of the cases, for instance element len =1 and put a note below the figure stating that this particular case is depicted. At least i would suggest that the Element Len field is depicted with 1 byte and separate the different element[i]

something like:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 3          |0|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Locator List Generation                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Element Len  |  Element[1]   |    Element[2] |   Element[3]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |
   ~                              ...                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           [The case of Element Len = 1 is depicted]


Besides, the signature defined in RFC3972 requires a 128-bit type tag for the message from the CGA Message Type name space that is specific to the usage of the CGA. In this case we would need to define such for shim and declare it in the IANA considerations, so that IANA assigns it. This 128 bit type tag is concatenated to what is being signed, so i guess this needs to be included here.

Does that mean we need to repeat the format from 3972?


well, no, i think that what is needed is to specify what is being signed here...


Send text.


i would suggest the following modification to the text (heavily inspired from Send spec)

5.14.5  CGA Signature Option Format

   When CGA is used for validation of one or more of the locators in the
Locator List Option, then the message in question will need to contain
   this option.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 5          |0|            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         CGA Signature                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   CGA Signature:

      A variable-length field containing a PKCS#1 v1.5 signature,
      constructed by using the sender's private key over the following
      sequence of octets:

      1. The 128-bit CGA Message Type tag [CGA] value for SHIM6, 0x4A
         30 5662 4858 574B 3655 416F 506A 6D48.  (The tag value has been
         generated randomly by the editor of this specification.).

      2. The Locator List Generation value of the correspondent Locator
         List Option.

      3. The subset of locators included in the correspondent Locator
         List Option which validation method is set to CGA. The locators
         MUST be included in the order they are listed in the Locator
         List Option.




In SEND they have decided to include in the option a hash of the public key used for signing, i guess this is for supporting multiple keys, but i am not sure we need this here...
I don't know if we want to include something else in the signature...

In addition, in the IANA considerations section the additional text would be needed:


   This document defines a new 128-bit value under the CGA Message Type
   [CGA] namespace, 0x4A30 5662 4858 574B 3655 416F 506A 6D48.


Furthermore, i guess we need to specify what is being signed here. I guess it doesn't makes sense to sign the whole locator list, since some of them are validated using HBAs. So a possible approach would be to extract from the locator list all of those that are validated through the CGA and sign those (ordered as they are included in the locator list),

I was assuming that would be specified in the HBA draft.

but the HBA draft doesn't talk about signatures, since HBAs don't need them Signatures are used when HBA features are not used and regular CGAs are used

 But we can
specify it in either draft I guess.

How does Send/CGA prevent replays? Wouldn't that imply we need to sign
more (the generation number?).

yes

What is easiest to describe and perhaps implement is to sign the whole
Update Message, but (except the signature option itself which we could
require to be last). But that would be a bit odd in the sense that a
locator preference option, when sent together with a locator list option
using CGA, would be signed. But when the locator preference option is
sent by itself it wouldn't be signed.


agree

In any case, I don't see a problem with signing the whole Locator List
option (plus whatever other pieces are needed) i.e. include any
HBA-verified prefixes.


well this could be done either way: or signing only those locators which verification method is CGA or the whole list. the text above considers the first option, but i am fine either way for now


In section 7.5  Sending I1 messages
   If, after several retransmissions, there is no response, then most
likely the peer does not implement the shim6 protocol, or there could
   be a firewall that blocks the protocol.
I guess that this depends on whether there is an ongoing communication or not. If there is an ongoing communication, then we can assume that the ulid is reachable, so if no answer is received then is because of any of the two above reasons. However, if there is not an ongoing communication or if a failure has just occurred, maybe it is that the ULID selected in unreachable and other locators/ULIDs should be tried. Not sure what to do in this case...

Failures before the context are up would need to be handled using
"failures during initial contact" wouldn't they?
Or is there a middle place where
 - ULP has communicated a bit, but no context is created yet
 - a failure occurs
This would be complex to handle I think.


my thoughts were more simpler than that... :-)
I was considering the case where the shim context is establsihed upfront, before the communication is established. For instance, suppose a host that knows that it usually establishes communications with other peer and that it wants to establish a shim session up front for upcoming communications... Not sure we want to do that, but i think that several times we considered the possibility that the shim session is established upfront (for instance when considering using shim for dealing with initial contact failures)

In section 9.  Handling ICMP Error Messages
   But when the shim on the transmitting side
replaces the ULIDs in the IP address fields with some other locators, then an ICMP error coming back will have a "packet in error" which is not a packet that the ULP sent. Thus the implementation will have to apply the reverse mapping to the "packet in error" before passing the
   ICMP error up to the ULP.
but the ICMP error won't have a shim payload header so, it won't be processed by the shim, right? or are we supposing that thee shim will inspect all packets (having the shim header or not) and identify ICMP error packets and in those inspect whther the inside packet contains a shim header and then do the processing? I am especially concerned with the inspect all packets part, since i think i remeber talking in the meeting that this would result in important performance issues...

It's not all packets. An implementation which conforms to RFC 1122 need
a mechanism to pass ICMP errors (as some form of error notifications) to the ULPs on the host based on the next hdr values in the packet in error. Thus if the packet in error was TCP it passes an event to a TCP specific
handler. And if the packet is SHIM6, it passes an event to a SHIM6
specific handler. This handler can then figure out what to do next,
based on the following next hdr value in the packet in error.

ok i didn't knew this


Suggestions on how I can clarify this?


i would keep as it is, and we can assume that informed readers will know what i didn't :-)

regards, marcelo