Subject: Re: Fragmentation-related security issues

From: RJ Atkinson <[email-masked]>
Date: Wed, 4 Jan 2012 08:57:11 -0500

Earlier, Mark Andrews wrote:
> Atomic fragments > 1280 should not appear in the network.  
> Atomic fragments <= 1280 are a expected part of the IPv6 landscape.  
> For TCP they should be rare.  
> For UDP it depends on the protocol running on top of UDP.  
> PMTUD relying on PTB is just not reliable.

To the best of my understanding, the above is correct.

Cheers,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jan 2012 08:13:27 +1300

> To the best of my understanding, the above is correct.

The last point is IMHO the most significant. As far as I'm
concerned, PMTUD for IPv4 has *never* been reliable, and for
many years I clamped the MTU on my laptop at 576 to avoid
constant connectivity failures while on travel. That seems
to have become unnecessary in recent years since 1500 became
almost universal as the link MTU (but PMTUD is still unreliable).

I see no reason to expect that PMTUD will be more reliable for
IPv6 than for IPv4. 1280 is reasonably safe today only because
1500 link MTU is widespread.

On 2012-01-05 05:19, Dan Wing wrote:

> We can clamp TCP MSS on our various translator devices.

However, this won't help with TCP implementations whose
MSS negotiation is broken. I haven't seen that failure
mode on translated paths, but I have seen it on 6to4 paths,
where one end wanted to reduce the MSS and the other end
was stuck on 1440.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Jan 2012 14:06:31 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Wednesday, January 04, 2012 11:13 AM
> To: [email-masked]
> Subject: Re: Fragmentation-related security issues
> 
> IPv6 than for IPv4.

I think a lot is now hinging on the assumption that
PMTUD for IPv6 works. Unlike the situation for IPv4,
I see no reason to expect that PMTUD for IPv6 will
be unreliable.

> 1280 is reasonably safe today only because

On this point, I agree that 1280 fits within the current
day Internet cell size (1500) even if there are multiple
levels of encapsulation. But, I see no reason why IPv6
PMTUD can't be counted upon for larger than 1280.

Fred
[email-masked]

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 04 Jan 2012 19:22:19 -0300

> I see no reason to expect that PMTUD for IPv6 will

It has been found to break, already -- as a result of firewalls
filtering ICMPv6 messages, are some intermediate systems with
inappropriate rate limiting for all ICMPv6 traffic.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Wed, 04 Jan 2012 19:40:48 -0300

>> For TCP they should be rare.  

How about stateless translators translating TCP traffic, and sending an
ICMPv6 PTB traffic for the same reasons as discussed for the UDP case?

Thanks,

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 4 Jan 2012 17:46:26 -0500

> ICMPv6 PTB traffic for the same reasons as discussed for the UDP case?

Good point.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Jan 2012 14:50:41 -0800

> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Wednesday, January 04, 2012 2:22 PM
> To: Templin, Fred L
> Cc: Brian E Carpenter; [email-masked]

If IPv6 PMTUD breaks, it is due to violations of the specs.
If IPv6 PMTUD breaks, then we are lost - time to give up
and design a different protocol?

Fred

---

From: Fernando Gont <[email-masked]>
Date: Wed, 04 Jan 2012 20:52:02 -0300

>> ICMPv6 PTB traffic for the same reasons as discussed for the UDP case?

My take is: As noted in draft-gont-6man-ipv6-atomic-fragments, just
process such atomic fragments as non fragmented traffic, and be done
with it. Trying to make a distinction whether atomic fragments <1280
should be allowed or not (and trying to figure out what we'd break in
the process) doesn't make much sense, since such fragments can be
processed (regardless of their size) as safely as non-fragmented traffic.

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jan 2012 15:55:06 +1300

> and design a different protocol?

The point is that paranoid firewalls will turn this into an
arms race - if they are paranoid enough to block ICMP PTB,
which apparently many are, why wouldn't they block any other
signalling mechanism - especially a new one?

That's why RFC 4821 describes MTU probing hidden in the transport
layer, where hopefully firewalls would let it be. You will
probably look in vain for widely deployed versions of RFC 4821.

     Brian

---

From: Jared Mauch <[email-masked]>
Date: Thu, 5 Jan 2012 07:41:55 -0500

> probably look in vain for widely deployed versions of RFC 4821.

We will not win a discussion with people who fail to understand how
the technology actually works vs their concept of it.

I'm waiting for the likely millions of users to have trouble when
dns more often requires TCP transport for some queries/responses.

I see the side-effects of this in my name server logs daily for
people not doing EDNS and who can't handle udp packets past 512.

Jan  5 07:35:55 puck named[26179]: fldsmtpe02.verizon.com/A: changed rcode: setting NOEDNS flag in adb cache for '192.76.85.133#53'

We can't protect people from doing something wrong/outside spec, nor
do I feel we should spend a lot of effort catering to solve their
problems for them.  Just because my prius can go off-road doesn't
mean it's the intended operation nor is covered when I abuse it.

Same goes here, vendors and carriers need to tell customers their
security technique is unsupported and will break things.  It's
not the role of the carrier to solve all the problems for the
customer who does something weird in this case, unless they're
the one creating the problem by using 1000 mtu links w/ IPv6.

Any vendor that supports setting the mtu under 1280 on IPv6 should
face a reality check sooner vs later.

- Jared

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jan 2012 09:33:23 -0800

Hi Brian, 

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Wednesday, January 04, 2012 6:55 PM
> To: Templin, Fred L
> Cc: Fernando Gont; [email-masked]

SEAL provides a new signalling mechanism called "SCMP"
which is intended to traverse firewalls that might block
ICMP messages. SCMP messages include a message signature
that the source node can use to determine whether the
packet-in-error corresponds to a packet the node actually
sent. Under what reasonable circumstances could even a
paranoid firewall block that?

> probably look in vain for widely deployed versions of RFC 4821.

Thanks for mentioning RFC4821 - it occurred to me last
nite that I had mis-spoken and that RFC4821 is advisable
even if the network is making a best effort to return
ICMPs. I think this is fairly well captured in Section
5.6 of RFC6434. However, the use or non-use of RFC4821
does not excuse the network from making a best effort
to return the required *CMPs.

Fred

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Jan 2012 00:58:50 +1100

In message <[email-masked]>, Jared Mauch 

> Jan  5 07:35:55 puck named[26179]: fldsmtpe02.verizon.com/A: changed rcode: s
> etting NOEDNS flag in adb cache for '192.76.85.133#53'

That one isn't outside the spec.  The server answers EDNS queries,
it's just a old (RFC 1035), server.

What is outside the spec in silently dropping queries if you see
something you don't understand.  RFC 1035 has a error code (FORMERR)
for that and it should be returned.

What is unconscionable, is firewall vendor shipping products in
2012 which don't handle protocol changes from 1999.  EDNS is
designed to interoperate with RFC 1035 bases servers.

Dropping of fragmented packets is slowly disappearing with the
deployment of DNSSEC.  The DNS get slower and slower and eventually
people start complaining.  Fixing firewalls that are dropping
fragmented packets usually just requires a rule change.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 01:21:19 -0300

> probably look in vain for widely deployed versions of RFC 4821.

The problem with RFC4821 (assumming the ICMP-free variant) is that it
has a longer convergnece time that ICMP-enabled PMTU.

That's why people think of RFC4821 as a mechanism for PMTUD blackhole
detection rathern than as a repalcement for traditional PMTUD (i.e., you
use the transport-layer probes when it looks like tradictional PMTUD is
not working (possibly as a result of filtered ICMP error messages)).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 18:19:54 -0300

> paranoid firewall block that?

"SEAL? We're not using it, so let's block it"

[Without knowing about SEAL or its packets' syntax]

Bottom-line is that unless you're protocol cannot easily be
distinguished from some widely-deployed/widely-used protocol, it's
probably going to be blocked. That's why e.g. firewall-friendly
protocols tend to run over HTTP.

P.S.: I'm just the messenger...

Thanks,

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jan 2012 17:08:32 -0800

Hi Fernando, 

> Sent: Wednesday, January 04, 2012 8:21 PM
> To: Brian E Carpenter
> Cc: Templin, Fred L; [email-masked]

RFC4821 works even if there are no ICMPs, but will
converge more quickly if there are ICMPs. That is why
RFC4821 should be a SHOULD for hosts, and generation
of ICMPs should be a MUST for routers.

> not working (possibly as a result of filtered ICMP error messages)).

The two are complementary. RFC4821 is about the
endpoints of communication working together in
parallel with the network providing a best-effort
service. It's just that sometimes the network
best-effort service is not good enough.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 5 Jan 2012 17:14:45 -0800

Hi Fernando, 

> Sent: Thursday, January 05, 2012 1:20 PM
> To: Templin, Fred L

SEAL can be (con)seal(ed) within any outer layers of
encapsulation. For example, it can appear as an IP
protocol number, a TCP/UDP port number, or even
buried within additional layers of encapsulation
involving, e.g., TLS/SSL, IPsec, etc.

I think the LISP team is counting on being able to
ship things around within a simple outer IP/UDP
encapsulation, so SEAL should be equally deployable
(or not) within such an encapsulation.

> protocols tend to run over HTTP.

SEAL can do that, too...

> P.S.: I'm just the messenger...

Right - no one is blaming you.

Fred

---

From: Fernando Gont <[email-masked]>
Date: Thu, 05 Jan 2012 22:20:19 -0300

> of ICMPs should be a MUST for routers.

Agreed.

> The two are complementary. 

It was originally meant to be a replacement for traditional PMTUD. Then
it was relaxed and RFC4821 allowed for it to be used only in the
presence of PMTUD blackholes.

Thanks,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Jan 2012 21:08:09 -0500

Are we really prepared to say that there can be no new protocosl at the 
Internet or Transport layer, ever again.  Not even new extensions?

I do not think most folks ahve that view.
But taht is the corrolary of the assumption that
a) things need to work through firewalls
b) that firewalls will and should block everything that they do not 
understand.

There are contexts where such behavior is appropriate, and possibly even 
necessary.
But if we take that as our design assumption, then we might as well stop 
lots of work we are doing.

Yours,
Joel

---

From: Havard Eidnes <[email-masked]>
Date: Fri, 06 Jan 2012 09:27:36 +0100 (CET)

>> The problem with RFC4821 (assumming the ICMP-free variant) is
>> that it has a longer convergnece time that ICMP-enabled PMTU.
>

Does not this also imply that ICMP-generating routers MUST use a
globally unique IPv6 address as the source of the ICMP?

Regards,

- Håvard

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 6 Jan 2012 09:51:53 +0100

Hmmm while I understand the reasoning, I do not think that forcing core routers to generate ICMP PTB messages is a good idea as this is done by the route processor and not in silicon. This would be a nice DoS ;-)

Their ICMP generation is usually rate limited (actually there is a HW rate limiter on too-big packets).

OTOH, core should never have a 'small MTU' link, so, this should be only a problem in theory.

-éric

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Havard Eidnes
> Sent: vendredi 6 janvier 2012 09:28
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 06 Jan 2012 00:31:47 -0300

> Internet or Transport layer, ever again.  Not even new extensions?

I'm personally ready to admit that new transport protocols and new IPv4
options are hard to deploy.

> a) things need to work through firewalls

I don't have such assumption. Actually, I'm rather in the camp of what
somebody wrote years ago "firewall-friendly protocols are really
'firewall-unfriendly', because they are designed to circumvent the
policies specified by the firewall administrators".

So I don't think that one should necessarily design protocols to work
through firewalls. BUt at the same time one shouldn't be surprised if
they don't.

> b) that firewalls will and should block everything that they do not

Well, firewalls generally enforce policies, and they generally try to
allow the "good" stuff in, while keeping the "bad" stuff out, with the
assumption that "good" is only that stuff that "I know and I need".

When one wears the protocol-development hat, that's frustrating and
ugly. When one wears the "security" hat, that's the obvious way to avoid
trouble for stuff that you don't really need).

As usual, it's also clear that taking things to the extreme is usually
not a good idea.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Jared Mauch <[email-masked]>
Date: Fri, 6 Jan 2012 12:03:17 -0500

> As usual, it's also clear that taking things to the extreme is usually

I have to say, I'm certainly not as defeatist as Joel sounds, but I do
hear his concern.

I do firmly believe we can't solve everyones broken network issues or
keep them from doing something wrong.

- Jared

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jan 2012 09:07:54 -0800

> From: Havard Eidnes [mailto:[email-masked]] 
> Sent: Friday, January 06, 2012 12:28 AM
> To: Templin, Fred L
> Cc: [email-masked]; [email-masked]; [email-masked]

AFAICT, the normative reference is RFC4443, as cited
in RFC6434.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jan 2012 09:27:48 -0800

Hi Fernando, 

> Behalf Of Fernando Gont
> Sent: Thursday, January 05, 2012 7:32 PM
> To: Joel M. Halpern
> Cc: [email-masked]; Brian E Carpenter
> Subject: To firewall or not to firewall (was: Re: 
> Fragmentation-related security issues)
> 

SEAL at least does not require a new transport protocol
nor new IP options in all of its manifestations, i.e.,
it can be embedded within TCP/UDP just fine.
 
> through firewalls. BUt at the same time one shouldn't be surprised if

Some of these encapsulation approaches get around this
by maintaining multiple candidate paths, and testing
to find one or more of the candidates that are working.
A candidate path that would traverse a blocking firewall
would just be seen as a non-working path.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Jan 2012 09:20:38 +1300

> keep them from doing something wrong.

Somehow, it doesn't seem as if RFC 2979 is having much impact these days.
It's definitely off-topic for this WG, but maybe it's time that the IETF
faced up to firewalls in the same way that BEHAVE has faced up to NATs.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Jan 2012 09:26:45 +1300

> AFAICT, the normative reference is RFC4443, as cited

As I think we noticed recently in some other thread, there is
therefore an operational requirement that all routers must
possess at least one GUA. As far as I know, some routers can work
just fine for all other purposes with only link-local addresses.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Jan 2012 09:36:03 +1300

> not working (possibly as a result of filtered ICMP error messages)).

"when it looks like" is the statement of an AI problem. I think we
were talking about the case where the happy-eyeballs heuristic fails
inelegantly because SYN/ACK worked fine but PMTUD (or possibly MSS
negotiation) failed. In that case, the happy-eyeballs state machine
as described so far doesn't know that it needs to do anything more.
So this pretty much needs to be done spontaneously by the transport
layer, if SYN/ACK succeeds but no further traffic occurs.

I have nothing to suggest for UDP.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jan 2012 12:52:11 -0800

Hi Brian, 

> Sent: Friday, January 06, 2012 12:27 PM
> To: Templin, Fred L
> Cc: Havard Eidnes; [email-masked]; [email-masked]

So - can't the router just autoconfigure a ULA and use
it as the SA for ICMPs?

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Fri, 06 Jan 2012 15:57:54 -0500

Fred,

> So - can't the router just autoconfigure a ULA and use

The ULA will have no meaning for ICMP messages that leave the
administrative domain.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Jan 2012 10:06:36 +1300

> The ULA will have no meaning for ICMP messages that leave the

That doesn't matter, to avoid the issue covered in the long thread
"Routers forwarding packet with link local source" on v6ops last
month.

    Brian C

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jan 2012 13:44:05 -0800

Hi Brian, 

> Behalf Of Brian Haberman
> Sent: Friday, January 06, 2012 12:58 PM
> To: [email-masked]

I don't think it needs to have meaning - unless there
were some application that wanted to try to geo-locate
the router based on the IP address? The ULA would only
be there to placate the routing system, which cannot
forward packets with LL source addresses.

In general, though, AFAICT the source address of an
ICMP error message such as PTB coming from the network
of little value to the node in deciding whether to
accept it.

Thanks - Fred

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Jan 2012 08:32:54 +0000

* Brian E. Carpenter:

> That doesn't matter,

How do you implement BCP38 filters if the address lacks clear ownership?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Fernando Gont <[email-masked]>
Date: Sat, 07 Jan 2012 01:26:52 -0300

On 01/06/2012 05:36 PM, Brian E Carpenter wrote:
> negotiation) failed.

Sorry, I meant "it looks like PMTUD messages are being dropped" -- and
yes, "looks like", because you cannot tell for sure.

>  In that case, the happy-eyeballs state machine

Sorry, not sure what you're referring to.

I just said that PLPMTU has a long convergence time, and hence it's
usually seen as a "PMTU blackhole detection/recovery mechanism", rather
than as a replacement of traditional PMTUD.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Jan 2012 06:37:23 -0300

> How do you implement BCP38 filters if the address lacks clear ownership?

Same thing would happen as it currently happens with ICMP error messages
sourced from private addresses: some get "mysteriously" dropped. -- i.e.
using ULAs for the source address of ICMPv6 messages seems like a very
bad idea.

Thanks,

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Jan 2012 07:18:54 -0800

> Sent: Monday, January 09, 2012 1:37 AM
> To: Florian Weimer
> Cc: Brian Haberman; [email-masked]; Brian E Carpenter

What I care most about is the value of the source address
from the perspecive of the ICMP message recipient. I think
no matter the source address scope, the recipinet cannot
use the source address alone as a means of authenticating
the ICMP, since there is no guarantee that BCP38 is
universally implemented. Right?

Thanks - Fred

---

From: Florian Weimer <[email-masked]>
Date: Mon, 09 Jan 2012 15:24:19 +0000

> universally implemented. Right?

No, the recipient faces a different, even more difficult challenge: even
if the source address is validated based on BCP38, the recipient doesn't
know if the node with that address was actually on the path of the
triggering packet and thus authorized to send the ICMP message.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Jan 2012 07:34:41 -0800

> From: Florian Weimer [mailto:[email-masked]] 
> Sent: Monday, January 09, 2012 7:24 AM
> To: Templin, Fred L
> Cc: Fernando Gont; Brian Haberman; [email-masked]; Brian E Carpenter

Right - that is exactly why something like SEAL is useful.
With SEAL, the ICMP recipient can know that the sender of
the ICMP message is on-path, because the packet-in-error
contains a digital signature that the recipient himself
provided. That is why I said that the source address alone
cannot be used to authenticate the ICMP message.

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Mon, 9 Jan 2012 09:08:03 -0800

On Jan 6, 2012, at 8:26 PM, Fernando Gont wrote:

> I just said that PLPMTU has a long convergence time

Frankly, that sounds like an implementation issue. If we're willing to set IW=10, it seems like one should be able to send the initial burst, or at least the first retransmission, with messages of several sizes and see what works. In other words, if the MSS is 9K (I wish), send a 9K, a 4K, a 1500 byte IP datagram (eg 1440 byte payload), and 1280. If we get an Ack in the subsequent RTT acknowledging 8192 bytes, we learned something, and if the only Ack acknowledges 1280, we learned something.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Jan 2012 10:08:54 -0800

> Behalf Of Templin, Fred L
> Sent: Monday, January 09, 2012 7:35 AM
> To: Florian Weimer
> Subject: RE: Fragmentation-related security issues
> 
>  
> 

BTW, this is specified in Section 4.4.7 of

http://tools.ietf.org/html/draft-templin-intarea-seal-42

(it does not appear in RFC5320, which will be deprecated
by the RFC-to-be based on this new draft.)

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jan 2012 09:40:45 +1300

> Frankly, that sounds like an implementation issue. If we're willing to set IW=10, it seems like one should be able to send the initial burst, or at least the first retransmission, with messages of…

Right. And the point Fernando queried in my previous message was
simply trying to say "happy eyeballs doesn't do this" - it will leave
the user hanging if TCP connects but PMTUD or MSS negotiation fails.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jan 2012 09:49:39 +1300

> using ULAs for the source address of ICMPv6 messages seems like a very

It's a bad idea, but using link-local is even worse, because those
MUST be dropped.

I don't think ULAs will be stopped by ingress filters in the case that
people over on v6ops were complaining about, where ICMP echo replies
were sent by ISP-internal routers. ULAs will be stopped by ingress
filters if a customer site uses them for ICMP replies.

We agree that using a globally routeable address is best.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 09 Jan 2012 12:42:50 -0300

On 01/09/2012 12:18 PM, Templin, Fred L wrote:
> from the perspecive of the ICMP message recipient. 

That depends on what you're using ICMP for. If it's for troubleshootinf
(ping, traceroute, etc.), the Source Address has some value. If the
ICMPs are meant to be processed by a transport layer (as in PMTUD), the
the Source Address is of no value (it could correspond to the address of
any intervenning router, and since virtually every router could be an
"intervenning router", you cannoT "validate" the source address.

> I think

Right. See RFC 5927.

Thanks,

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Jan 2012 09:53:43 -0800

Please see below for a pre-draft for using the Subnetwork
Encapsulation and Adaptation Layer (SEAL) as an IPv6 extension
header. This extension header can be used by the source to
defeat off-path spoofing of ICMPv6 error messages. When the
source and destination share a secret symmetric key used for
calculating the integrity check vector, the extension header
also provides the destination with data origin authentication
and anti-replay.

Please send any comments to the list,

Fred

--- cut here ---

Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                          January 10, 2012
Expires: July 13, 2012

                     The SEAL IPv6 Extension Header
                       draft-templin-sealopt.txt

Abstract

   The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a
   mid-layer header designed for the encapsulation of an inner network
   layer packet within outer network layer headers.  SEAL also supports
   a transport mode of operation, where the inner payload corresponds to
   an ordinary transport layer payload.  However, SEAL can also provide
   benefit when used as an IPv6 extension header.  Namely, the SEAL
   header when used as an extension header contains a digital signature
   (inserted by the source) that covers the leading 128 bytes of the
   payload beginning with the SEAL header itself.  The source can
   thereafter use the digital signature to verify that any ICMPv6
   mesages received actually came from a router on the path.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 13, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Templin                   Expires July 13, 2012                 [Page 1]

Internet-Draft                    SEAL                      January 2012

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  SEAL IPv6 Extension Header  . . . . . . . . . . . . . . . . . . 3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5

Templin                   Expires July 13, 2012                 [Page 2]

Internet-Draft                    SEAL                      January 2012

1.  Introduction

   The Subnetwork Encapsulation and Adaptation Layer (SEAL)
   [I-D.templin-intarea-seal] provides a mid-layer encapsulation
   designed for the encapsulation of an inner network layer packet
   within outer network layer headers.  SEAL also supports a transport
   mode of operation, where the encapsulated payload corresponds to an
   ordinary transport layer protocol payload.  It is in essence a close
   analogy of the GRE encapsulation format [RFC1701].

   However, SEAL can also provide benefit when used as an IPv6 extension
   header [RFC2460].  Namely, the SEAL header when used as an IPv6
   extension header contains a digital signature (inserted by the
   source) that covers the leading 128 bytes of the payload beginning
   with the SEAL header itself.  The source can thereafter use the
   digital signature to verify that any ICMPv6 mesages received actually
   came from a router on the path.

2.  SEAL IPv6 Extension Header

   The SEAL IPv6 extension header is formatted as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |Hdr Ext Len = 2|    SEAL Header (format TBD)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Identification                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Integrity Check Vector (ICV)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Reserved                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: SEAL IPv6 Extension Header Format

   Next Header (8)  an 8-bit field that encodes the next header Internet
      Protocol number the same as for the IPv4 protocol and IPv6 next
      header fields.

   Next Header Length (8)  an 8-bit length of the extension header
      measured in 8-byte words.  Set to 2.

   SEAL Header (16)
      a 16-bit field that controls the operation of SEAL.  Format TBD.

Templin                   Expires July 13, 2012                 [Page 3]

Internet-Draft                    SEAL                      January 2012

   Identification (32)
      a 32-bit per-packet identification field.  Set to a monotonically-
      incrementing 32-bit value for each SEAL packet transmitted,
      beginning with 0.

   Integrity Check Vector (ICV) (32)
      a 32-bit header integrity check value.  Covers the leading 128
      bytes of the packet beginning with the SEAL extension header (or
      up to the end of the packet).  The value 128 is chosen so that at
      least the SEAL header as well as the inner packet network and
      transport layer headers are covered by the integrity check.

   The IPv6 source inserts a SEAL extension header whenever it wants to
   ensure that any resulting ICMPv6 error messages [RFC4443] came from a
   router on the path and not from an off-path attacker.  When the
   source receives an ICMPv6 error message, it verifies that the ICV
   value is correct based on a secret hashing algorithm of its choosing.
   The source should choose a hashing algorithm that would make it
   virtually impossible for an off-path attacker to guess.

3.  IANA Considerations

   The IANA is instructed to allocate an IPv6 extension header for SEAL.

4.  Security Considerations

   The SEAL extension header can be used to verify that ICMPv6 messages
   wre delivered by an on-path router and not an off-path attacker.  The
   header may also be used fro other authenticating purposes, e.g., if
   the destination shares a symmetric secret key with the source then
   the destination can verify that messages actually came from the
   source.  The packet identification field can also be used for anti-
   replay sequencing.

5.  Acknowledgments

   TBD.

6.  References

6.1.  Normative References

   [I-D.templin-intarea-seal]
              Templin, F., "The Subnetwork Encapsulation and Adaptation

Templin                   Expires July 13, 2012                 [Page 4]

Internet-Draft                    SEAL                      January 2012

              Layer (SEAL)", draft-templin-intarea-seal-42 (work in
              progress), December 2011.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

6.2.  Informative References

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701, October 1994.

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: [email-masked]

Templin                   Expires July 13, 2012                 [Page 5]