[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