File: rfc2356.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1346 lines) | stat: -rw-r--r-- 53,196 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346






Network Working Group                                      G. Montenegro
Request for Comments: 2356                                      V. Gupta
Category: Informational                           Sun Microsystems, Inc.
                                                               June 1998


              Sun's SKIP Firewall Traversal for Mobile IP

Status of This Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   The Mobile IP specification establishes the mechanisms that enable a
   mobile host to maintain and use the same IP address as it changes its
   point of attachment to the network. Mobility implies higher security
   risks than static operation, because the traffic may at times take
   unforeseen network paths with unknown or unpredictable security
   characteristics. The Mobile IP specification makes no provisions for
   securing data traffic.  The mechanisms described in this document
   allow a mobile node out on a public sector of the internet to
   negotiate access past a SKIP firewall, and construct a secure channel
   into its home network.

   In addition to securing traffic, our mechanisms allow a mobile node
   to roam into regions that (1) impose ingress filtering, and (2) use a
   different address space.

Table of Contents

   1. Introduction ...............................................    2
   2. Mobility without a Firewall ................................    4
   3. Restrictions imposed by a Firewall .........................    4
   4. Two Firewall Options: Application relay and IP Security ....    5
   4.1 SOCKS version 5 [4] .......................................    5
   4.2 SKIP [3] ..................................................    6
   5. Agents and Mobile Node Configurations ......................    8
   6. Supporting Mobile IP: Secure Channel Configurations ........    9
   6.1 I: Encryption only Outside of Private Network .............    9
   6.2 II: End-to-End Encryption .................................   10
   6.3 III: End-to-End Encryption, Intermediate Authentication ...   10



Montenegro & Gupta           Informational                      [Page 1]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   6.4 IV: Encryption Inside and Outside .........................   10
   6.5 Choosing a Secure Channel Configuration ...................   11
   7. Mobile IP Registration Procedure with a SKIP Firewall ......   11
   7.1. Registration Request through the Firewall ................   12
   7.1.1. On the Outside (Public) Network ........................   13
   7.1.2. On the Inside (Private) Network ........................   14
   7.2. Registration Reply through the Firewall ..................   14
   7.2.1. On the Inside (Private) Network ........................   15
   7.2.2. On the Outside (Public) Network ........................   15
   7.3. Traversal Extension ......................................   16
   8. Data Transfer ..............................................   18
   8.1. Data Packet From the Mobile Node to a Correspondent Node .   18
   8.2. Data Packet From a Correspondent Node to the Mobile Node .   19
   8.2.1 Within the Inside (Private) Network .....................   20
   8.2.2. On the Outside (Public) Network ........................   21
   9. Security Considerations ....................................   21
   Acknowledgements ..............................................   22
   References ....................................................   22
   Authors' Addresses ............................................   23
   Full Copyright Statement ......................................   24

1. Introduction

   This document specifies what support is required at the firewall, the
   Mobile IP [1] home agent and the Mobile IP mobile node to enable the
   latter to access a private network from the Internet.  For example, a
   company employee could attach his/her laptop to some Internet access
   point by:

      a)   Dialing into a PPP/SLIP account on an Internet service
           provider's network.

      b)   Connecting into a 10Base-T or similar LAN network available
           at, for example, an IETF terminal room, a local university,
           or another company's premises.

   Notice that in these examples, the mobile node's relevant interface
   (PPP or 10Base-T) is configured with an IP address different from
   that which it uses "normally" (i.e. at the office). Furthermore, the
   IP address used is not necessarily a fixed assignment. It may be
   assigned temporarily and dynamically at the beginning of the session
   (e.g. by IPCP in the PPP case, or DHCP in the 10Base-T case).

   The following discussion assumes a network configuration consisting
   of a private network separated by a firewall from the general
   Internet or public network.  The systems involved are:





Montenegro & Gupta           Informational                      [Page 2]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


      Private Network

           A protected network separated from the Internet by hosts
           enforcing access restrictions (firewalls). A private network
           may use a private address space, and its addresses may not
           even be routable by the general internet.

      Public Network

          The Internet at large. Hosts are able to communicate with each
          other throughout the public network without firewall-imposed
          restrictions.

      Mobile Node (MN)

          Its permanent address falls within the range of the private
          network. The user removes the system from its home network,
          and connects it to the Internet at another point.  The
          mechanisms outlined in this discussion render this mobility
          transparent:  the mobile node continues accessing its home
          network and its resources exactly as if it were still within
          it.  Notice that when the mobile node leaves its home
          network, it may migrate both within and outside of the
          private network's boundaries. As defined by Mobile IP [1], a
          mobile node uses a care-of address while roaming.

      Home Agent (HA) for the mobile node

         Serves as a location registry and router as described in the
         Mobile IP IETF draft.

      Foreign Agent (FA)

         Serves as a registration relayer and care of address for the
         mobile node as described in the Mobile IP IETF draft.

      Correspondent Node (CH)

         A system that is exchanging data packets with the mobile
         node.

      Firewall (FW)

         The system (or collection of systems) that enforces access
         control between the private network and the general Internet.
         It may do so by a combination of functions such as application
         gatewaying, packet filtering and cryptographic techniques.




Montenegro & Gupta           Informational                      [Page 3]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   The mechanisms described in this document allow a mobile node out on
   a public sector of the network to negotiate access past a SKIP
   firewall, and construct a secure channel into its home network.  This
   enables it to communicate with correspondent nodes that belong to the
   private network, and, if bi-directional tunnels are used, with
   external hosts that are reachable when the mobile node is at home.
   The mobile node enjoys the same level of connectivity and privacy as
   it does when it is in its home network.

   This document does not address the scenario in which the mobile node
   attempts to access its private network, while within another private
   network.

   Sections 2 and 3 provide an overview of the environment being
   considered and the restrictions it imposes.  Section 4 examines
   firewall technologies. Section 5 discusses the best mode of operation
   of the participating entities from the point of view of Mobile IP.
   Section 6 discusses possible configuration for the secure channel.
   Finally, packet formats are the topic of sections 7 and 8.

2. Mobility without a Firewall

   Suppose the mobile node is roaming throughout the general Internet,
   but its home network is not protected by a firewall. This is
   typically found in academic environment as opposed to corporate
    networks.

   This works as prescribed by Mobile IP [1]. The only proviso is that
   the mobile node would most probably operate with a co-located address
   instead of using a separate foreign agent's care-of address.  This is
   because, at least in the near term, it is far more likely to be able
   to secure a temporary care-of-address than it is to find a foreign
   agent already deployed at the site you are visiting. For example:

   -   Internet Service Provider: pre-assigns customers IP addresses,
       or assigns them out dynamically via PPP's address negotiation.

   -   An IETF terminal room may pre-assign addresses for your use or
       offer DHCP services.

   -   Other locations probably would offer DHCP services.

3. Restrictions imposed by a Firewall

   The firewall imposes restrictions on packets entering or leaving the
   private network. Packets are not allowed through unless they conform
   to a filtering specification, or unless there is a negotiation
   involving some sort of authentication.



Montenegro & Gupta           Informational                      [Page 4]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   Another restriction is imposed by the separation between private
   addresses and general Internet addresses. Strictly speaking, this is
   not imposed by a firewall, but by the characteristics of the private
   network. For example, if a packet destined to an internal address
   originates in the general Internet, it will probably not be
   delivered.  It is not that the firewall drops it. Rather, the
   Internet's routing fabric is unable to process it. This elicits an
   ICMP host unreachable packet sent back to the originating node.

   Because of this, the firewall MUST be explicitly targeted as the
   destination node by outside packets seeking to enter the private
   network. The routing fabric in the general Internet will only see the
   public address of the firewall and route accordingly.  Once the
   packet arrives at the firewall, the real packet destined to a private
   address is recovered.

4. Two Firewall Options: Application relay and IP Security

   Before delving into any details, lets examine two technologies which
   may provide firewall support for mobile nodes:

   -   application relaying or proxying, or

   -   IP Security.

   To understand the implications, let's examine two specific schemes to
   accomplish the above: SOCKS version 5 and SKIP.

4.1 SOCKS version 5 [4]

   There is an effort within the authenticated firewall traversal WG
   (aft) of the IETF to provide a common interface for application
   relays.

   The solution being proposed is a revised specification of the SOCKS
   protocol. Version 5 has been extended to include UDP services as
   well.  The SOCKS solution requires that the mobile node -- or another
   node on its behalf -- establish a TCP session to exchange UDP traffic
   with the FW. It also has to use the SOCKS library to encapsulate the
   traffic meant for the FW. The steps required by a SOCKS solution are:

   -   TCP connection established to port 1080 (1.5 round trips)

   -   version identifier/method selection negotiation (1 round trip)

       -   method-dependent negotiation. For example, the
           Username/Password Authentication [5] requires 1 round trip:




Montenegro & Gupta           Informational                      [Page 5]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


           1. client sends a Username/Password request
           2. FW (server) responds

           The GSS-API negotiation requires at least 3 round trips:

           1. client context establishment (at least 1 round trip)
           2. client initial token/server reply (1 round trip)
           3. message protection subnegotiation (at least 1 round trip)

   -   (finally) SOCKS request/reply (1 round trip)

   This is a minimum of 4 (6 with GSS-API) round-trips before the client
   is able to pass data through the FW using the following header:

      +----+------+------+----------+----------+----------+
      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
      +----+------+------+----------+----------+----------+
      | 2  |  1   |  1   | Variable |    2     | Variable |
      +----+------+------+----------+----------+----------+

   Bear in mind that the above must be done each time the mobile
   registers a new care-of address. In addition to this inefficiency,
   this scheme requires that we use UDP to encapsulate IP datagrams.
   There is at least one commercial network that does this, but it is
   not the best solution.

   Furthermore, SOCKS defines how to establish authenticated
   connections, but currently it does not provide a clear solution to
   the problem of encrypting the traffic.

   This header contains the relay information needed by all parties
   involved to reach those not directly reachable.

4.2 SKIP [3]

   Alternatively, traffic from the mobile node to the firewall could be
   encrypted and authenticated using a session-less IP security
   mechanism like SKIP. This obviates the need to set up a session just
   to exchange UDP traffic with the firewall.

   A solution based on SKIP is very attractive in this scenario, as no
   round trip times are incurred before the mobile node and the firewall
   achieve mutual trust: the firewall can start relaying packets for the
   mobile node as soon as it receives the first one.  This, of course,
   implies that SKIP is being used with AH [7] so that authentication
   information is contained in each packet.  Encryption by using ESP [6]
   is also assumed in this scenario, since the Internet at large is
   considered a hostile environment.  An ESP transform that provides



Montenegro & Gupta           Informational                      [Page 6]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   both authentication and encryption could be used, in which case the
   AH header need not be included.

   The firewall and the mobile node may be previously configured with
   each other's authenticated Diffie-Hellman public components (also
   known as public values).  Alternatively, they could exchange them in
   real-time using any of the mechanisms defined by the SKIP protocol
   (on-line certificate directory service or certificate discovery
   protocol). Home agents and the firewall also MUST have, be able to
   exchange or obtain each other's public components.

   There are other proposals besides SKIP to achieve IP layer security.
   However, they are session-oriented key management solutions, and
   typically imply negotiations spanning several round-trip times before
   cryptographically secure communications are possible.  In this
   respect they raise similar concerns to those outlined previously in
   the discussion on SOCKS-based solutions.  Others have arrived at
   similar conclusions regarding the importance of session-less key
   management for Mobile IP applications [8].

   Another advantage of SKIP is its support for nomadic applications.
   Typically, two hosts communicating via a secure IP layer channel use
   the IP source and destination addresses on incoming packets to arrive
   at the appropriate security association. The SKIP header can easily
   supersede this default mechanism by including the key ID the
   recipient must use to obtain the right certificate.

   The key id is specified by two fields in the SKIP header:

      1) a name space identifier (NSID) to indicate which of the
         possible name spaces is being used, and,

      2) a master key identifier (MKID) that uniquely indicates (within
         the given name space) an id to use in fetching the proper
         certificate.

   As an example, by setting NSID to 1 and MKID to its home address, a
   mobile node tells a receiver "ignore the IP source and use my home
   address instead to look up my public component". Similarly, setting
   NSID to 8 enables using Unsigned Diffie-Hellman (UDH) certificates.

   In this case, the MKID is set to the MD5 hash of the DH public
   component [10].

   In addition to the NSID/MKID feature, Mobile IP is best supported by
   an appropriate policy at the SKIP firewall in the form of a "nomadic"
   access control list entry. This is an entry which is filtered by key
   ID, instead of by IP source address, as is the usual case. It



Montenegro & Gupta           Informational                      [Page 7]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   translates to "allow access from any IP source address for a given
   NSID/MKID combination".  Furthermore, incoming packets MUST have an
   AH header, so that after properly authenticating them, the firewall
   establishes a "current address" or "dynamic binding" for the nomadic
   host.  The NSID/MKID combination determines which key should be used
   with the nomadic host [9].

   Notice that this supports Mobile IP, because the mobile node always
   initiates contact. Hence, the SKIP firewall has a chance to learn the
   mobile node's "current address" from an incoming packet before it
   attempts to encrypt an outgoing packet.

   However, this precludes the use of simultaneous bindings by a mobile
   node.  At the firewall, the last Registration Request sent by the
   mobile node replaces the association between its permanent address
   and any prior care-of address. In order to support simultaneous
   bindings the firewall must be able to interpret Mobile IP
   registration messages.

   Section 7.2.2 discusses another advantage of making the firewall
   understand Mobile IP packet formats.

   In what follows we assume a SKIP-based solution.

5. Agents and Mobile Node Configurations

   Depending on which address it uses as its tunnel endpoint, the Mobile
   IP protocol specifies two ways in which a mobile node can register a
   mobility binding with its home agent.

      a)   an address advertised for that purpose by the foreign agent

      b)   an address belonging to one of the mobile node's interfaces
           (i.e. operation with a co-located address).

   From the firewall's point of view, the main difference between these
   two cases hinges on which node prepares the outermost encrypting
   encapsulation.  The firewall MUST be able to obtain the Diffie-
   Hellman public component of the node that creates the outermost SKIP
   header in an incoming packet. This is only possible to guarantee in
   case "b", because the mobile node and the firewall both belong to the
   same administrative domain. The problem is even more apparent when
   the mobile node attempts a Registration Request.  Here, the foreign
   agent is not just a relayer, it actually examines the packet sent by
   the mobile node, and modifies its agent services accordingly. In
   short, assuming the current specification of Mobile IP and the
   current lack of trust in the internet at large, only case "b" is
   possible. Case "a" would require an extension (e.g. a "relay"



Montenegro & Gupta           Informational                      [Page 8]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   Registration Request), and modifying code at the home agent, the
   firewall and the foreign agent.

   Assuming that the firewall offers a secure relay service (i.e.
   decapsulation and forwarding of packets), the mobile node can reach
   addresses internal to the private network by encapsulating the
   packets in a SKIP header and directing them to the firewall.

   Therefore, It is simplest to assume that the mobile node operates
   with a co-located address.

6. Supporting Mobile IP: Secure Channel Configurations

   The mobile node participates in two different types of traffic:
   Mobile IP registration protocol and data. For the sake of simplicity,
   the following discussion evaluates different secure channel
   configurations by examining the initial Registration Request sent by
   the mobile node to its home agent.

   Assuming the mobile node operates with a co-located address, it can
   communicate directly with the firewall.  The latter is able to reach
   the home agent in the private network. Also, the firewall MUST be
   able to authenticate the mobile node.

   The following channel configurations assume the mobile node operates
   with a co-located address. The region between the HA (home agent) and
   the FW (firewall) is a private network. The region between the FW and
   the MN (mobile node) is the outside or public network.

6.1 I: Encryption only Outside of Private Network


   HA            FW                        MN
                  <=====================>  SKIP (AH + ESP)
    <----------------------------------->  Registration Request path

   The traffic is only encrypted between the mobile node out on the
   general Internet, and the firewall's external interface. This is
   minimum required. It is the most desirable configuration as the more
   expensive encrypted channel is only used where it is necessary: on
   the public network.










Montenegro & Gupta           Informational                      [Page 9]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


6.2 II: End-to-End Encryption

   Another possible configuration extends the encrypted tunnel through
   the firewall:

   HA            FW                        MN
    <===================================>  SKIP (AH + ESP)
    <----------------------------------->  Registration Request path

   This limits the firewall to perform a simple packet relay or
   gatewaying function. Even though this could be accomplished by using
   the proper destination NSID in the packet, in practice it is probably
   unrealizable. The reason is that this alternative is probably not
   very popular with computer security personnel, because authentication
   is not carried out by the firewall but by the home agent, and the
   latter's security is potentially much weaker than the former's.

6.3 III: End-to-End Encryption, Intermediate Authentication

   A third alternative is to allow the firewall to be party to the
   security association between the home agent and the mobile node.
   After verifying authentication (AH header), the firewall forwards the
   encrypted packet (ESP hdr) to the home agent.

   HA            FW                        MN
                  <+++++++++++++++++++++>  SKIP authentication
    <===================================>  SKIP encryption
    <----------------------------------->  Registration Request path

   Here, SKIP is used to provide intermediate authentication with end-
   to-end security. Although possible, this option implies that the
   participating entities disclose their pairwise long-term Diffie-
   Hellman shared secret to the intermediate node.

   Whereas Option 2 above is probably not agreeable to security and
   system administration personnel, option 3 is unsavory to the end
   user.

6.4 IV: Encryption Inside and Outside

   HA            FW                        MN
    <============><=====================>  SKIP (AH + ESP)
    <----------------------------------->  Registration Request path

   Traffic is encrypted on the public as well as on the private network.
   On the public network, encryption is dictated by a security
   association between the mobile node and the firewall.  On the private
   network, it is dictated by a security association between the home



Montenegro & Gupta           Informational                     [Page 10]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   agent and the firewall.

6.5 Choosing a Secure Channel Configuration

   A potential problem in both options 2 and 3 is that their end-to-end
   channel components assume that the mobile node and the home agent can
   exchange IP traffic directly with each other. This is generally not
   the case, as the Internet routing fabric may not have routes to
   addresses that belong to private networks, and the private routing
   fabric may ignore how to route to public addresses -- or doing so may
   be administratively restricted.  Therefore, it is necessary for
   packets to be addressed directly to the firewall, and indirectly --
   via some tunneling or relaying capability -- to the real destination
   on the other side of the firewall.

   Options 1 and 4 are essentially equivalent. The latter may be
   considered overkill, because it uses encryption even within the
   private network, and this is generally not necessary. What is
   necessary even within the private network is for the home agent to
   add an encapsulation (not necessarily encrypted) so as to direct
   datagrams to the mobile node via the firewall. The type of
   encapsulation used determines the difference between options 1 and 4.
   Whereas option 4 uses SKIP, option 1 uses a cleartext encapsulation
   mechanism.  This is obtainable by, for example, using IP in IP
   encapsulation [2].

   Options 1 and 4 are mostly interchangeable. The difference is, of
   course, that the former does not protect the data from eavesdroppers
   within the private network itself. This may be unacceptable in
   certain cases. Traffic from some departments in a company (for
   example payroll or legal) may need to be encrypted as it traverses
   other sections of the company.

   In the interest of being conservative, in what follows we assume
   option 4 (i.e. traffic is encrypted on the general Internet, as well
   as within the private network.

   Since the firewall is party to the security associations governing
   encryption on both the public and private networks, it is always able
   to inspect the traffic being exchanged by the home agent and the
   mobile node. If this is of any concern, the home agent and mobile
   node could set up a bi-directional tunnel and encrypt it.

7. Mobile IP Registration Procedure with a SKIP Firewall

   When roaming within a private network, a mobile node sends
   Registration Requests directly to its home agent. On the public
   Internet, it MUST encapsulate the original Registration Request in a



Montenegro & Gupta           Informational                     [Page 11]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   SKIP packet destined to the firewall.  The mobile node MUST
   distinguish between "inside" and "outside" addresses. This could be
   accomplished by a set of rules defining the address ranges.
   Nevertheless, actual installations may present serious difficulties
   in defining exactly what is a private address and what is not.

   Direct human input is a very effective method: it may be obvious to
   the user that the current point of attachment is outside its private
   network, and it should be possible to communicate this knowledge to
   the mobile node software.

   The home agent must also distinguish between "inside" and "outside"
   addresses, but lacks the potential benefit of direct user input.
   Accordingly, it should be possible for the mobile node to communicate
   that knowledge to the home agent. To accomplish this we define a
   Traversal Extension to the Registration Requests and Replies.  This
   extension is also useful when traversing multiple firewalls.

   In spite of the above mechanisms, errors in judgement are to be
   expected.  Accordingly, the firewall SHOULD be configured such that
   it will still perform its relaying duties even if they are
   unnecessarily required by a mobile node with an inside care-of
   address.

   Upon arriving at a foreign net and acquiring a care-of address, the
   mobile node must first -- before any data transfer is possible --
   initiate a registration procedure. This consists of an authenticated
   exchange by which the mobile node informs its home agent of its
   current whereabouts (i.e. its current care-of address), and receives
   an acknowledgement. This first step of the protocol is very
   convenient, because the SKIP firewall can use it to dynamically
   configure its packet filter.

   The remainder of this section shows the packet formats used.  Section
   7.1 discusses how a mobile node sends a Registration Request to its
   home agent via the SKIP firewall. Section 7.2 discusses how the home
   agent send the corresponding Registration Reply to the mobile node.
   Section 7.3 defines the Traversal Extension for use with Registration
   Requests and Replies.

7.1. Registration Request through the Firewall

   The mobile node arrives at a foreign net, and using mechanisms
   defined by Mobile IP, discovers it has moved away from home. It
   acquires a local address at the foreign site, and composes a
   Registration Request meant for its home agent.  The mobile node must
   decide whether this packet needs to be processed by SKIP or not.




Montenegro & Gupta           Informational                     [Page 12]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   This is not a simple rule triggered by a given destination address.
   It must be applied whenever the following conditions are met:

      a)   the mobile node is using a care-of address that does not
           belong to the private network (i.e. the mobile node is
           currently "outside" its private network), and

      b)   either of:

           b1)   the source address of the packet is the mobile node's
                 home address (e.g. this packet's endpoints are
                 dictated by a connection initiated while at home), or

           b2)   the source address of the packet is the care-of
                 address and the destination address belongs to the
                 private network

   Since the above conditions are mobility related, it is best for the
   Mobile IP function in the node to evaluate them, and then request the
   appropriate security services from SKIP.

7.1.1. On the Outside (Public) Network

   The SKIP module must use the firewall destination address and the
   firewall's certificate in order to address and encrypt the packet.
   It encrypts it using SKIP combined with the ESP [6] protocol and
   possibly the AH [7] protocol.

   The SKIP header's source NSID equals 1, indicating that the Master
   Key-ID is the mobile node's home address. Notice that the IP packet's
   source address corresponds to the care-of address -- an address whose
   corresponding public component is unknown to the firewall.

   It is also possible to use Unsigned Diffie-Hellman public components
   [10].  Doing so greatly reduces SKIP's infrastructure requirements,
   because there is no need for a Certificate Authority. Of course, for
   this to be possible the principals' names MUST be securely
   communicated.

   REGISTRATION REQUEST: BETWEEN THE MOBILE NODE AND THE FIREWALL
   +---------------+----------+----+-----+--------------+--------------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
   +---------------+----------+----+-----+--------------+--------------+

     IP Hdr (SKIP):
        Source          mobile node's care-of address
        Destination     firewall's public (outside) address




Montenegro & Gupta           Informational                     [Page 13]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


     SKIP Hdr:
        Source          NSID = 1
                        Master Key-ID = IPv4 address of the mobile node
        Destination     NSID = 0
                        Master Key-ID = none
     Inner IP Hdr:
        Source          mobile node's care-of address
        Destination     home agent's address

7.1.2. On the Inside (Private) Network

   The SKIP Firewall's dynamic packet filtering uses this information to
   establish a dynamic binding between the care-of address and the
   mobile node's permanent home address.

   The destination NSID field in the above packet is zero, prompting the
   firewall to process the SKIP header and recover the internal packet.
   It then delivers the original packet to another outbound interface,
   because it is addressed to the home agent (an address within the
   private network). Assuming secure channel configuration number 4, the
   firewall encrypts the packet using SKIP before forwarding to the home
   agent.

   REGISTRATION REQUEST: BETWEEN THE FIREWALL AND THE HOME AGENT
   +---------------+----------+----+-----+--------------+--------------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Request |
   +---------------+----------+----+-----+--------------+--------------+

     IP Hdr (SKIP):
        Source          firewall's private (inside) address
        Destination     home agent's address

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 0
                        Master Key-ID = none
     Inner IP Hdr:
        Source          mobile node's care-of address
        Destination     home agent's address

7.2. Registration Reply through the Firewall

   The home agent processes the Registration Request, and composes a
   Registration Reply. Before responding, it examines the care-of
   address reported by the mobile node, and determines whether or not it
   corresponds to an outside address.  If so, the home agent needs to
   send all traffic back through the firewall.  The home agent can



Montenegro & Gupta           Informational                     [Page 14]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   accomplish this by encapsulating the original Registration Reply in a
   SKIP packet destined to the firewall (i.e. we assume secure channel
   configuration number 4).

7.2.1. On the Inside (Private) Network

   The packet from the home agent to the mobile node via the SKIP
   Firewall has the same format as shown above. The relevant fields are:

   REGISTRATION REPLY: BETWEEN THE HOME AGENT AND THE FIREWALL
   +---------------+----------+----+-----+--------------+------------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
   +---------------+----------+----+-----+--------------+------------+

     IP Hdr (SKIP):
        Source          home agent's address
        Destination     firewall's private (inside) address

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 0
                        Master Key-ID = none
     Inner IP Hdr:
        Source          home agent's address
        Destination     mobile node's care-of address

7.2.2. On the Outside (Public) Network

   The SKIP Firewall recovers the original Registration Reply packet and
   looks at the destination address: the mobile node's care-of address.

   The SKIP Firewall's dynamic packet filtering used the initial
   Registration Request (Secton 7.1) to establish a dynamic mapping
   between the care-of address and the mobile node's Master Key-ID.
   Hence, before forwarding the Registration Reply, it encrypts it using
   the mobile node's public component.

   This dynamic binding capability and the use of tunneling mode ESP
   obviate the need to extend the Mobile IP protocol with a "relay
   Registration Request". However, it requires that the Registration
   Reply exit the private network through the same firewall that
   forwarded the corresponding Registration Request.

   Instead of obtaining the mobile node's permanent address from the
   dynamic binding, a Mobile IP aware firewall could also obtain it from
   the Registration Reply itself. This renders the firewall stateless,
   and lets Registration Requests and Replies traverse the periphery of



Montenegro & Gupta           Informational                     [Page 15]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   the private network through different firewalls.

   REGISTRATION REPLY: BETWEEN THE FIREWALL AND THE MOBILE NODE
   +---------------+----------+----+-----+--------------+------------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | Reg. Reply |
   +---------------+----------+----+-----+--------------+------------+

     IP Hdr (SKIP):
        Source          firewall's public (outside) address
        Destination     mobile node's care-of address

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 1
                        Master Key-ID = IPv4 addr of the mobile node
     Inner IP Hdr:
        Source          home agent's address
        Destination     mobile node's care-of address

7.3. Traversal Extension

   The Traversal Extension MAY be included by mobile nodes in
   Registration Requests, and by home agents in Registration Replies.
   As per Section 3.6.1.3 of [1], the Traversal Extension must appear
   before the Mobile-Home Authentication Extension.  A Traversal
   Extension is an explicit notification that there are one or more
   traversal points (firewalls, fireridges, etc) between the mobile node
   and its home agent. Negotiating access past these systems may imply a
   new authentication header, and possibly a new encapsulating header
   (perhaps as part of tunnel-mode ESP) whose IP destination address is
   the traversal address.

   Negotiating access past traversal points does not necessarily require
   cryptographic techniques.  For example, systems at the boundary
   between separate IP address spaces must be explicitly targetted
   (perhaps using unencrypted IP in IP encapsulation).

   A mobile node SHOULD include one Traversal Extension per traversal
   point in its Registration Requests. If present, their order MUST
   exactly match the order in which packets encounter them as they flow
   from the mobile node towards the home agent.

   Notice that there may be additional firewalls along the way, but the
   list of traversal points SHOULD only include those systems with which
   an explicit negotiation is required.





Montenegro & Gupta           Informational                     [Page 16]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   Similarly, the home agent SHOULD include one Traversal Extension per
   traversal point in its Registration Replies.  If present, their order
   MUST exactly match the order in which packets encounter them as they
   flow from the home agent to the mobile node.

   A Traversal Extension does not include any indication about how
   access is negotiated. Presumably, this information is obtained
   through separate means. This document does not attempt to solve the
   firewall discovery problem, that is, it does not specify how to
   discover the list of traversal points.

   As per section 1.9 of [1], the fact that the type value falls within
   the range 128 to 255 implies that if a home agent or a mobile node
   encounter a Traversal Extension in a Registration Request or Reply,
   they may silently ignore it. This is consistent with the fact that
   the Traversal Extension is essentially a hint.

    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      |    Length     |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MN to HA Traversal Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 HA to MN Traversal Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

        129

      Length

         10

      Reserved

         0

      MN to HA Traversal Address

         The IP address of the an intermediate system or firewall
         encountered by datagrams sent by the mobile node towards the
         home agent. Typically, this is the external address of a
         firewall or firewall complex.






Montenegro & Gupta           Informational                     [Page 17]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


         This field MUST be initialized in Registration Requests.  In
         Registration Replies, it is typically all 0's, otherwise, the
         mobile node SHOULD interpret it as a hint.

      HA to MN Traversal Address

         The IP address of an intermediate system or firewall
         encountered by datagrams sent by the home agent towards the
         mobile node. Typically, this is the internal address of a
         firewall or firewall complex.

         This field MUST be initialized in Registration Replies.  In
         Registration Requests, it is typically all 0's, otherwise, the
         home agent SHOULD interpret it as a hint.

8. Data Transfer

   Data transfer proceeds along lines similar to the Registration
   Request outlined above.  Section 8.1 discusses data traffic sent by a
   mobile node to a correspondent node. Section 8.2 shows packet formats
   for the reverse traffic being tunneled by the home agent to the
   mobile node.

8.1. Data Packet From the Mobile Node to a Correspondent Node

   The mobile node composes a packet destined to a correspondent node
   located within the private network.

   The Mobile IP function in the mobile node examines the Inner IP
   header, and determines that it satisfies conditions "a" and "b1" from
   Section 7.1. The mobile node requests the proper encryption and
   encapsulation services from SKIP.

   Thus, the mobile node with a co-located address sends encrypted
   traffic to the firewall, using the following format:

   DATA PACKET: FROM THE MOBILE NODE VIA THE FIREWALL
   +---------------+----------+----+-----+--------------+------+
   | IP Hdr (SKIP) | SKIP Hdr | AH | ESP | Inner IP Hdr | ULP  |
   +---------------+----------+----+-----+--------------+------+

     IP Hdr (SKIP):
        Source          mobile node's care-of address
        Destination     public (outside) address on the firewall







Montenegro & Gupta           Informational                     [Page 18]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


     SKIP Hdr:
        Source          NSID = 1
                        Master Key-ID = IPv4 address of the mobile node
        Destination     NSID = 0
                        Master Key-ID = none
     Inner IP Hdr:
        Source          mobile node's home address
        Destination     correspondent node's address

   The SKIP Firewall intercepts this packet, decrypts the Inner IP Hdr
   and upper-layer payload (ULP) and checks the destination address.
   Since the packet is destined to a correspondent node in the private
   network, the "Inner" IP datagram is delivered internally.  Once the
   SKIP firewall injects this packet into the private network, it is
   routed independently of its source address.

   As this last assumption is not always true, the mobile node may
   construct a bi-directional tunnel with its home agent. Doing so,
   guarantees that the "Inner IP Hdr" is:

     Inner IP Hdr:
        Source          care-of address
        Destination     home agent address

   When at home, communication between the the mobile node and certain
   external correspondent nodes may need to go through application-
   specific firewalls or proxies, different from the SKIP firewall.
   While on the public network, the mobile node's communication with
   these hosts, MUST use a bi-directional tunnel.

8.2. Data Packet From a Correspondent Node to the Mobile Node

   The home agent intercepts a packet from a correspondent node to the
   mobile node. It encapsulates it such that the Mobile IP encapsulating
   IP header's source and destination addresses are the home agent and
   care-of addresses, respectively. This would suffice for delivery
   within the private network. Since the current care-of address of the
   mobile node is not within the private network, this packet MUST be
   sent via the firewall. The home agent can accomplish this by
   encapsulating the datagram in a SKIP packet destined to the firewall
   (i.e. we assume secure channel configuration number 4).










Montenegro & Gupta           Informational                     [Page 19]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


8.2.1 Within the Inside (Private) Network

   From the home agent to the private (inside) address of the firewall
   the packet format is:

   DATA PACKET: BETWEEN THE HOME AGENT AND THE FIREWALL
   +--------+------+----+-----+--------+--------+-----+
   | IP Hdr | SKIP | AH | ESP | mobip  | Inner  | ULP |
   | (SKIP) | Hdr  |    |     | IP Hdr | IP Hdr |     |
   +--------+------+----+-----+--------+--------+-----+

     IP Hdr (SKIP):
        Source          home agent's address
        Destination     private (inside) address on the firewall

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 0
                        Master Key-ID = none

     Mobile-IP IP Hdr:
        Source          home agent's address
        Destination     care-of address

     Inner IP Hdr:
        Source          correspondent node's address
        Destination     mobile node's address

     ULP:               upper-layer payload

   The packet format above does not require the firewall to have a
   dynamic binding. The association between the mobile node's permanent
   address and it care-of address can be deduced from the contents of
   the "Mobile-IP IP Hdr" and the "Inner IP Hdr".

   Nevertheless, a nomadic binding is an assurance that currently the
   mobile node is, in fact, at the care-of address.













Montenegro & Gupta           Informational                     [Page 20]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


8.2.2. On the Outside (Public) Network

   The SKIP firewall intercepts the packet, and recovers the Mobile IP
   encapsulated datagram. Before sending it out, the dynamic packet
   filter configured by the original Registration Request triggers
   encryption of this packet, this time by the SKIP firewall for
   consumption by the mobile node.  The resultant packet is:

   DATA PACKET: BETWEEN THE FIREWALL AND THE MOBILE NODE
   +--------+------+----+-----+--------+--------+-----+
   | IP Hdr | SKIP | AH | ESP | mobip  | Inner  | ULP |
   | (SKIP) | Hdr  |    |     | IP Hdr | IP Hdr |     |
   +--------+------+----+-----+--------+--------+-----+

     IP Hdr (SKIP):
        Source          firewall's public (outside) address
        Destination     mobile node's care-of address

     SKIP Hdr:
        Source          NSID = 0
                        Master Key-ID = none
        Destination     NSID = 1
                        Master Key-ID = IPv4 address of the mobile node

     Mobile-IP IP Hdr:
        Source          home agent's address
        Destination     care-of address

     Inner IP Hdr:
        Source          correspondent node's address
        Destination     mobile node's address

     ULP:               upper-layer payload

   At the mobile node, SKIP processes the packets sent by the firewall.
   Eventually, the inner IP header and the upper-layer packet (ULP) are
   retrieved and passed on.

9. Security Considerations

   The topic of this document is security. Nevertheless, it is
   imperative to point out the perils involved in allowing a flow of IP
   packets through a firewall. In essence, the mobile host itself MUST
   also take on responsibility for securing the private network, because
   it extends its periphery. This does not mean it stops exchanging
   unencrypted IP packets with hosts on the public network.  For
   example, it MAY have to do so in order to satisfy billing
   requirements imposed by the foreign site, or to renew its DHCP lease.



Montenegro & Gupta           Informational                     [Page 21]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   In the latter case it might filter not only on IP source address, but
   also on protocol and port numbers.

   Therefore, it MUST have some firewall capabilities, otherwise, any
   malicious individual that gains access to it will have gained access
   to the private network as well.

Acknowledgements

   Ideas in this document have benefited from discussions with at least
   the following people: Bill Danielson, Martin Patterson, Tom Markson,
   Rich Skrenta, Atsushi Shimbo, Behfar Razavi, Avinash Agrawal, Tsutomu
   Shimomura and Don Hoffman. Jim Solomon has also provided many helpful
   comments on this document.

References

   [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

   [2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
       1996.

   [3] A. Aziz and M. Patterson, Design and Implementation of SKIP,
       available on-line at http://skip.incog.com/inet-95.ps. A
       previous version of the paper was presented at INET '95 under
       the title Simple Key Management for Internet Protocols (SKIP),
       and appears in the conference proceedings under that title.

   [4] Leech, M., Ganis, M., Lee, Y, Kuris, R., Koblas, D., and
       L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.

   [5] Leech, M., "Username/Password Authentication for SOCKS V5",
       RFC 1929, March 1996.

   [6] Atkinson, R., "IP Encapsulating Payload", RFC 1827, August
       1995.

   [7] Atkinson, R., "IP Authentication Header", RFC 1826, August
       1995.

   [8] Stephen Kent, message to the IETF's IPSEC mailing list,
       Message-Id: <v02130500ae569a3e904e@[128.89.30.29]>, September
       6, 1996.

   [9] Tom Markson, private communication, June 12, 1996.






Montenegro & Gupta           Informational                     [Page 22]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


   [10] A. Aziz, T. Markson, H. Prafullchandra. Encoding of an
        Unsigned Diffie-Hellman Public Value. Available on-line as
        http://skip.incog.com/spec/EUDH.html.

Authors' Addresses

   Gabriel E. Montenegro
   Sun Microsystems, Inc.
   901 San Antonio Road
   Mailstop UMPK 15-214
   Mountain View, California 94303

   Phone: (415)786-6288
   Fax: (415)786-6445
   EMail: gabriel.montenegro@Eng.Sun.COM


   Vipul Gupta
   Sun Microsystems, Inc.
   901 San Antonio Road
   Mailstop UMPK 15-214
   Mountain View, California 94303

   Phone: (415)786-3614
   Fax: (415)786-6445
   EMail: vipul.gupta@Eng.Sun.COM

























Montenegro & Gupta           Informational                     [Page 23]

RFC 2356      Sun's SKIP Firewall Traversal for Mobile IP      June 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.























Montenegro & Gupta           Informational                     [Page 24]