Re: [savi] Potential issue for all SAVI mechanisms?

[Jean-Michel Combes <[e-mail]>]

2011/8/24 Joel M. Halpern <[e-mail]>:
> Without arguing about what document things belong in, the proposed text is
> just a paraphrase of one half of what "trusted port for dhcp" meands.
> the other half, "untrusted port for dhcp" means that if the Next Header
> value is detectably DHCP, but the port is not trusted for DHCP, it should be
> dropped.
> Those are, I believe already in the document.
>
> The issue we are discussing is what more should be said about the cases
> where the Next Header value can not be found.  This arises either when
> either fragmentation moves the next header to the next message, or extra
> headers move it outside of the parse capabilities of the device.

Yes, this is the issue.

>
> It is probably sufficient to simply note that the trusted port enforcement
> does not handle those cases.
>
> The reason for putting it in the MIX document is that there is a very
> similar issue for NS detection.

Yes. BTW, maybe, MIX deployment may complicate the situation too
because this includes many SAVI solutions (and so their consequent
drawbacks).

Best regards.

JMC.

>
> Yours,
> Joel
>
> On 8/23/2011 10:55 PM, Jun Bi wrote:
>>
>> I agree with Guang Yao.
>> thanks,
>> Jun Bi
>> *From:* Guang Yao <mailto:[e-mail]>
>> *Sent:* Monday, August 22, 2011 5:19 PM
>> *To:* Jean-Michel Combes <mailto:[e-mail]>
>> *Cc:* SAVI Mailing List <mailto:[e-mail]>
>> *Subject:* Re: [savi] Potential issue for all SAVI mechanisms?
>> Hi,
>> I agree with the text. However, in DHCP case, only DHCP message from
>> dhcp-trust and savi-validation port is processed by the SAVI device. So
>> I add the condition as follows.
>> -If the Next Header value inside the Fragment header is DHCP, / and if
>> the packet is from dhcp-trust port or SAVI-validation port/, the packet
>> is processed by the SAVI device,
>> If this condition can be implied from existing text, just remove it.
>> Besides, I wonder whether it is necessary to include this in the MIX
>> document, as MIX document doesn't specify the details of packet process.
>> If FCFS/DHCP/SEND can each handle this problem separately, MIX can also
>> handle this problem.
>>
>> Best regards,
>> Guang
>>
>> 2011/8/19 Jean-Michel Combes <[e-mail]
>> <mailto:[e-mail]>>
>>
>>    Hi,
>>
>>    I would like to come back on this point and find a consensus.
>>    Here is the text I propose to be added in the Security Considerations
>>    section of any SAVI solution document (i.e., FCFS, DHCP, SEND and MIX
>>    documents) as residential threats:
>>
>>    <TEXT: only keep ND for FCFS/SEND SAVI and only keep UDP(DHCP) for
>>    DHCP SAVI>
>>    o SAVI limitations
>>    In some cases, the SAVI device could not be able to process IP packets
>>    and so to update correctly the Binding Table. For example, this could
>>    be the case for encrypted packets (i.e., with IPsec/ESP) or fragmented
>>    packets. To mitigate this last case, the SAVI device SHOULD proceed as
>>    follows:
>>    - If the Next Header value inside the Fragment header is ND/UDP(DHCP),
>>    the packet is processed by the SAVI device,
>>    - If the Next Header value inside the Fragment header is not
>>    ND/UDP(DHCP) but there is a binding, the packet is processed by the
>>    SAVI device,
>>    - Else the packet is dropped and the incident is logged.
>>    </TEXT>
>>
>>    Comments/alternative text (deadline: 8-september-2011) are welcome!
>>
>>    Thanks in advance.
>>
>>    Best regards.
>>
>>    JMC.
>>
>>    2011/6/28 Jean-Michel Combes <[e-mail]
>>    <mailto:[e-mail]>>:
>>     > Hi Joel,
>>     >
>>     > 2011/6/28 Joel M. Halpern <[e-mail]
>>    <mailto:[e-mail]>>:
>>     >> I don't think this works.
>>     >> The question is not how often ND packets have that structure,
>>    but whether
>>     >> 1) Hosts will accept ND packets with that structure
>>     >> and
>>     >> 2) Other protocols will use that structure.
>>     >>
>>     >> If both of those are true, which they currently are, then a SAVI
>>    device
>>     >> can not detect an ND packet which is fragmented and hiding behind
>>     >> destination options.
>>     >> But, contrary to your resolution below, since other protocols
>>    use that
>>     >> construct, SAVI devices can not simply drop all packets that are
>>     >> fragmented and where the only visible next header is destination
>>    options
>>     >> (or AH, or ESP.) they would be dropping legitimate data packets.
>>     >
>>     > Yep, I missed this ... So, a new proposal:
>>     > - if the Next Header value inside the Fragment header is
>>    ND/UDP(DHCP),
>>     > the packet is processed by the SAVI device
>>     > - if the Next Header value inside the Fragment header is not
>>     > ND/UDP(DHCP) and there is a binding, the packet is processed by the
>>     > SAVI device
>>     > - else the packet is dropped and the incident is logged
>>     >
>>     >>
>>     >> It does not matter whether any legitimate sender of ND messages
>>    would
>>     >> ever use that construct.
>>     >>
>>     >> As far as I can tell, the only path to sanity here is for the
>>    hosts not
>>     >> to accept such packets.
>>     >> And that is a matter for 6man, not for SAVI. We should simply
>>    document
>>     >> this as a residual threat.
>>     >
>>     > IMHO, this is a matter for SAVI too, because, if the SAVI device is
>>     > not able to process fragmented ND/DHCP packets from a node to
>>     > correctly update the Binding Table, by default, any packet from this
>>     > node will be dropped by the SAVI device even if hosts accept such
>>     > packets.
>>     >
>>     > Cheers.
>>     >
>>     > JMC.
>>     >
>>     >>
>>     >> Yours,
>>     >> Joel
>>     >>
>>     >>
>>     >> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote:
>>     >>> Based on RFC 2460:
>>     >>> (1) the Next Header value inside the Fragment header identifies
>> the
>>     >>> first header of the Fragmentable Part of the original packet
>>     >>> (2) The Unfragmentable Part consists of the IPv6 header plus any
>>     >>> extension headers that must be processed by nodes en route to the
>>     >>> destination, that is, all headers up to and including the Routing
>>     >>> header if present, else the Hop-by-Hop Options header if
>>    present, else
>>     >>> no extension headers.
>>     >>> (3) Extension header order is: IPv6 header, Hop-by-Hop Options
>>    header,
>>     >>> Destination Options header, Routing header, Fragment header,
>>     >>> Authentication header, Encapsulating Security Payload header,
>>     >>> Destination Options header, upper-layer header
>>     >>>
>>     >>> So, as far as I can see, there are only 3 scenarios where the Next
>>     >>> Header value inside the Fragment header is not ND(including
>>    SEND, as
>>     >>> this is just ND options)/DHCP:
>>     >>> (a) AH
>>     >>> (b) ESP
>>     >>> (c) Destination Option
>>     >>>
>>     >>> IMHO, ND/DHCP messages with such extension headers are not
>>    common ...
>>     >>>
>>     >>>
>>     >>>> >
>>     >>>> > Then the SAVI devices can assume and require that the known
>>    ULP is
>>     >>>> > contained in the first fragment, thus they can determine
>>    whether a
>>     >>>> > packet is ND/DHCP/SEND, and reject any such packets that
>>    include a
>>     >>>> > fragment header.
>>     >>> Indeed, we could assume for each SAVI mechanism that:
>>     >>> - if the Next Header value inside the Fragment header is
>>    ND/UDP(DHCP),
>>     >>> the packet is processed
>>     >>> - else the packet is dropped and the incident is logged
>>     >>>
>>     >>> As SAVI has a site/link scope, with the logs, IMHO, it should be
>>     >>> easier for the SAVI admin to understand/solve the issue.
>>     >>>
>>     >>> Best regards.
>>     >>>
>>     >>> JMC.
>>     >>>
>>     >>>
>>     >>>
>>     >>
>>     >
>>    _______________________________________________
>>    savi mailing list
>>    [e-mail] <mailto:[e-mail]>
>>    https://www.ietf.org/mailman/listinfo/savi
>>
>> _______________________________________________
>> savi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/savi
>>
>>
>> _______________________________________________
>> savi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/savi
>