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

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jun 2011 06:49:51 -0700

-------- Original Message --------
Subject: Re: [savi] Potential issue for all SAVI mechanisms?
Date: Wed, 22 Jun 2011 06:39:15 -0700
From: Erik Nordmark <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked]

On 6/21/11 10:26 PM, marcelo bagnulo braun wrote:
> Right, the question is how comon is for legitimate users to send
> NDP/DHCP/SEND fragmented packets? IS there any concrete real useful
> situacion where this happens?

The way I read RFC 4861's
    The size of an ND packet including the IP header is limited to the
    link MTU.  When adding options to an ND packet, a node MUST NOT
    exceed the link MTU.
is that ND packets should not be fragmented. But the spec doesn't have
an explicit MUST NOT fragment.

I haven't looked at the DHCP and SEND RFCs.

> If not, maybe we could simply say that SAVI will ignore the fragmented
> packets.
> If yes, then it seems we may have a problem.

I don't think we can just ignore them, since that would assume that the
receivers would explicitly drop fragmented ND/DHCP/SEND packets, which
they are not required to do.

Can we always tell whether a packet, which might in theory have 2K of
Destination options, is a ND/DHCP/SEND packet? Clearly not unless RFC
2460 requires that some bytes of the ULP (TCP, UDP, ICMP, etc) header is
always in the first fragment. In practice it would be reasonable to
expect that. But it seems to be a protocol change to IPv6 to require
that senders must put the ULP header in the first fragment.

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.

    Erik

> Regards, marcelo
>
>
> El 22/06/11 06:35, Jun Bi escribió:
>> In the Ethernet environment, the MTU is 1500, DHCP reply is not a
>> large packet and it won't be fragmented.
>> Maybe the packet size of RA is large and might be fragmented, but it
>> is not processed in SAVI.
>>
>> thanks,
>> Jun Bi
>>
>> -----原始邮件----- From: Joel M. Halpern
>> Sent: Wednesday, June 22, 2011 8:17 AM
>> To: Jun Bi
>> Cc: Jean-Michel Combes ; SAVI Mailing List
>> Subject: Re: [savi] Potential issue for all SAVI mechanisms?
>>
>> I do not think this is a sufficient answer. Whether the device is a
>> switch or a router, reassembling or maintaining packet state across
>> fragements is a non-trivial undertaking.
>>
>> I can imagine some kludges to get around this, but they have broader
>> impact than just SAVI. (For example, rejecting first packets that do
>> not have enough information to determine whether or not they are
>> claiming to be RAs or DHCP replies.)
>>
>> Yours,
>> Joel
>>
>> On 6/21/2011 9:56 AM, Jun Bi wrote:
>>> Hi Jean-Michel,
>>>
>>> What we are talking about "savi switch" is a 2.5 layer switch (layer 2
>>> switch in data plan with layer 3-aware in controll/management plan).
>>> So what I know from switch vendor is that the 2.5 layer switch chip or
>>> the stronger CPU can handel it.
>>> For example, the chip can recongnize the Protocol ID field of IP packets
>>> to recongznie HDCP or NDP packets (even in fragments),
>>> then copy them to switch CPU. The CPU can handle it.
>>>
>>> The SAVI switch has been really implmented and deployed, so I did really
>>> see any problem in real network.
>>> BTW, it seems that SAVI switch doesn't snoop and process RA packets for
>>> binding, so maybe RA packet is different.
>>>
>>> thanks,
>>> Jun Bi
>>>
>>> -----原始邮件----- From: Jean-Michel Combes
>>> Sent: Tuesday, June 21, 2011 9:37 PM
>>> To: SAVI Mailing List
>>> Subject: [savi] Potential issue for all SAVI mechanisms?
>>>
>>> Hi,
>>>
>>> Maybe you already know that there is a discussion on v6ops/6man MLs
>>> about RA Guard evasion (cf.
>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html).
>>> One of the methods to perform this evasion is fragmentation: it seems
>>> that a L2 device would not be able to re-assemble all the fragments
>>> without an important extra-cost and so would not be able to determine
>>> whether or not the message is a Router Advertisement (cf.
>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html).
>>>
>>> Knowing that:
>>> (1) In common use-case, SAVI device is a L2 device
>>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection
>>>
>>> I am wondering whether or not fragmentation would not impact strongly
>>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could
>>> not update correctly the Binding Table and so what would be the
>>> consequences?
>>>
>>> I would appreciate comments from WG members, especially
>>> implementors/manufacturers, about this.
>>>
>>> Thanks in advance for your replies.
>>>
>>> Best regards.
>>>
>>> JMC.
>>> _______________________________________________
>>> savi mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/savi
>>> _______________________________________________
>>> savi mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/savi
>>
>> _______________________________________________
>> savi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/savi
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 28 Jun 2011 19:26:58 +0200

Hi,

> an explicit MUST NOT fragment.

This is a good point.

> that senders must put the ULP header in the first fragment.

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

> packet is ND/DHCP/SEND, and reject any such packets that include a

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Jun 2011 13:39:36 -0400

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.

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.

Yours,
Joel

---

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 28 Jun 2011 20:02:40 +0200

Hi Joel,

> (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

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